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