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

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 ?

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 ?

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.

The semantics of the arg to -t would be something like "the limit between the patches that will end up below <patches> and those that will end up above". I suppose "-t current" should be the default, so it may not even be necessary to expose "current" to the command-line.

The "conceptual algorithm" would be:
 1. stg pop <patches>
 2. stg push <patches>
 3. stg goto "where I was"

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

By default, consistently with "float", the <patches> (and hence everything originally under the target point) will end up applied if the target of the move was "within $applied" (ie. an applied patch or "current" - something we could call "below the surface", hi float and sink ;), and all patches that were applied (ie. those between the target and the former tip) will end up being reapplied, consistently with "sink".

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

A --dont-come-back flag of some sort will skip step 3 of the conceptual algorithm above. When the target will be in $applied, it will be the equivalent of "sink --nopush". When the target is in $unapplied, we will "goto <last of <patches>>" after reorering the unapplied patches. Never missed this one till now, but who knows, this side-effect might come handy.

Opinions ?