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

From: Karl Hasselström <kha@treskal.com>
Date: May 6, 2007, 10:49 UTC
Message-ID: <20070506104944.GB17498@diana.vm.bytemark.co.uk>
In-Reply-To: <20070505201307.GE19253@nan92-1-81-57-214-146.fbx.proxad.net>

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

Show 10 quoted lines

> 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.

Show 6 quoted lines

> 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. ;-)

Show 8 quoted lines

> 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.

Show 6 quoted lines

> 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