> Quoting Junio C Hamano <junkio@xxxxxxx>: > Subject: Re: [RFC] git-float > > "Michael S. Tsirkin" <mst@xxxxxxxxxxxxxxxxxx> 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 - 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
