Re: [RFC] git-float

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