[RFC] git-float

[RFC] git-float

[Michael S. Tsirkin]

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

-- 
MST

Re: [RFC] git-float

[Junio C Hamano]

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

Re: [RFC] git-float

[Michael S. Tsirkin]

> Quoting Junio C Hamano <junkio@cox.net>:
> Subject: Re: [RFC] git-float
> 
> "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.

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.

-- 
MST