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 ? -- Yann. PS: this RFC is known as "bury sink and float" ;) - 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