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

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

On 9/14/07, Karl Hasselström [off-list ref] wrote:

quoted

  $ 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@treskal.com
      www.treskal.com/kalle