[RFC] git-float

Hi! Here's a simple script I use to float a commit up the history - similiar to what stg float does if I understand it correctly.

Is this a good way to implement it? Would it make sense to have something like this in git tree? Drop me a note.

############################################################

#!/bin/bash

check_revision() {
	case $# in
	2)
		true
		;;
	*)
		echo "Unable to float $1: it does not match a single non-merge commit" >&2
		exit 2
		;;
	esac
}
ref=`git-rev-list --no-merges $1~1..$1`
check_revision "$1" $ref

git-rebase --onto $ref~1 $ref && git-cherry-pick $ref

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:

Because git-rebase or git-cherry-pick can be interrupted with a conflict, this is not a good _implementation_. The whole script needs to have the sequencing and continue logic similar to the one git-rebase has.

Incidentally, this is closely related to something that people have wanted to have for a long time, which is to cherry-pick series of commits.

One step of rebase and cherry-pick can be thought of as a "rotate a commit" operation. When you cherry-pick a commit C on top of where you are, the resulting tree is computed by applying the commit C's effect to the current tree via 3-way merge.

	git-merge-recursive C^ HEAD C

git-rebase without -m does the equivalent of the above "rotate a commit" operation using patch + apply (and fall back to merge if the patch does not cleanly apply) for performance reasons, but the principle is the same. And the commit message for the result is taken from C itself.

git-rebase can be decomposed into three stages:

 (1) find the sequence of commits to reapply;

 (2) find the commit to start rebuilding onto and reset to it;

 (3) one by one, rotate the commits you found in (1), with
     the sequencing support (--abort, --skip and --continue).

There is no reason, other than the fact that there is no other commit rotator in git suite that needs sequencing, that these three needs to be in a single program git-rebase.

The only difference with the above outline and your float is that after you finish step (1), you record "this commit also needs to be replayed at the end" information to the sequence.

The implementation of cherry-pick that takes commit range is also obvious; instead of the computation git-rebase does for step (1) above, we would allow arbitrary series of commits to be specified from the command line (most likely using the revision list notation A..B) to be replayed with the sequencing machinery.

So to summarize: you suggest creating a new low-level command that gets a list of commits and applies them, with the sequencing support (--abort, --skip and --continue). Then rewrite both cherry-pick and rebase on top of these, implement git float (and maybe git kill which does just git-rebase --onto $1~1 $1 I posted at some point) on top of this as well.