Re: [RFC] git-float

From: Junio C Hamano <junkio@cox.net>
Date: May 18, 2007, 00:31 UTC
Message-ID: <7v3b1v7z19.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070517211805.GA29259@mellanox.co.il>

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

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

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

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.

> Would it make sense to have something like this in git tree?

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.