Re: [StGit PATCH] It doesn't make sense to sink below an unapplied patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2007-09-14 12:18:17 -0400, Jon Smirl wrote:

> On 9/14/07, Karl Hasselström <kha@xxxxxxxxxxx> wrote:
>
> >   $ stg pop p2 p3
> >   $ stg push p3 p2
> >
> > Does this cover what you had in mind?
>
> Sure this works. I'm just wondering if it is a good idea to have
> separate reordering commands for patches that are applied vs
> unapplied. The separate commands confused me.
>
> Would it be better to simply prohibit reordering of apply patches
> and require that they be popped before they can be reordered? A
> sink/float that causes merge errors must be a mess to sort out.

It's not a mess, actually -- it's implemented in terms of push and pop
of single patches, so the theory is dead simple. (The push and pop
commands are also implemented in terms of push and pop of single
patches.)

> If you prohibit reordering of applied patches sink/float can be
> eliminated.

But they're useful! Though as I said earlier, they're implemented in
terms of push and pop, so they're technically redundant. But "sink p5
--to p2" would be "pop p3..p5 && push p5 p3 p4", which is more typing
(starting with applied patches p1, p2, p3, p4, p5).

> Another way to handle this would be to eliminate the ability of
> pop/push to reorder and extend sink/float to handle unapplied
> patches.

I think that I'd like the latter without the former -- that is,
teaching sink/float how to handle unapplied patches, and leaving
push/pop as is. That'll let you do what you tried to do in the first
place, and will leave us with a more redundant command set, but I
don't think that's bad.

Another idea that's been kicked around is to have a general reorder
command, that spawns an editor and lets you move around (and delete)
patch names until you're satisfied. (This too would be implemented in
terms of push and pop of single patches.)

-- 
Karl Hasselström, kha@xxxxxxxxxxx
      www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux