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