Re: [RFC PATCH] Rename "bury" back to "sink".

On 2007-05-05 22:13:07 +0200, Yann Dirson wrote:

The whole debate around burying, sinking and floating patches made
me think a bit more about this. So we have:

float:        move specified patches to top of stack
bury/float:   move specified patches to bottom of stack or any place
              in the stack identified by a nearby patch

All in all, that all "move specified patches to a specified place".
So wouldn't it be possible to end the debate by merging those
commands into a single "stg move" command ?

I like that idea.

  stg move patch1 --bottom
  stg move patch1 --top
  stg move patch1 --before other-patch
  stg move patch1 --after other-patch
  stg move patch1 --position 17 # move to absolute pos. 17 (bottom is 0)
  stg move patch1 --up 3        # move 3 steps up
  stg move patch1 --down 2      # move 2 steps down

Or something. It could also be made to work with patch ranges as well
as single patches.

Side note about the "stg move" name: yes it could possible to
mistake it for "move file" (especially as we don't have "stg mv").
My current state of mind would be to drop add/rm/cp from stgit, and
move the "stg cp" logic to a new git-cp command. This way, stgit
would just be about handling series of patches, with git being used
for the working-copy. Any opinions on this ?

I would be in favor; I like to think of stgit as extending rather than
providing a complete replacement for the plain git porcelain. But as I
recall, Catalin didn't share my view on this. Better let him answer
the question himself than rely on my memory, though. ;-)

Now to the new command. We could have something like:

 stg move -t base <patches>     <=> stg sink <patches>
 stg move -t <patch> <patches>  <=> stg sink -t <patch> <patches>
 stg move -t current <patches>  <=> stg float <patches>

Note the introduction of a new "curent" stg_id for the tip of the
stack.

Ah, I wrote my suggested syntax above before reading yours. I like
mine better, though. :-)

"-s [<series>]" would be allowed as an alternative to <patches>, so
"move" would be a strict superset of "float".

Another useful option would be to have --interactive open up an editor
with the patch names in it; the user could rearrange the lines any way
she pleased, and when the editor exits, the patch series is rearranged
to match.

If the target point is in $unapplied, then the command will be
equivalent to "stg pop <patches>" with those patches reordered at
the target (ie. no need to really execute steps 2 and 3 above).
That's no rocket science, but a useful I have already missed, eg.
when I just want to move the patches away from my working set
(nowadays we could hide them, but that may not be always adequate).

Sounds very good.

Opinions?

Lots, as you just saw. :-)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle