Equivalent of the most general case git rebase --onto COMMIT1 COMMIT2 COMMIT3?

[rulatir]

What is the equivalent of the most general case of rebase:

git rebase --onto COMMIT1 COMMIT2 COMMIT3

?

[mhagger]

COMMIT3 is not interesting, because it is equivalent to

git checkout $COMMIT3
git rebase --onto $COMMIT1 $COMMIT2

So let's focus on the latter. How should it be handled by git-imerge? In my opinion it is ambiguous and the best strategy will vary on a case-by-case basis. Sometimes it would be best to do

BASE=$(git merge-base $COMMIT2 HEAD)
git imerge drop $BASE..$COMMIT2
git imerge rebase $COMMIT1

Sometimes the other order might work better:

git imerge rebase $COMMIT1
git imerge drop $COMMIT1..$COMMIT_THAT_USED_TO_BE_COMMIT2

Sometimes some other (perhaps hybrid?) approach might work best.

It would be nice if git-imerge would support these workflows better, but it's not super clear what it should even do.

[rulatir]

My specific use case is rebasing several branches that form a chronological chain. They are placed at various spots along a VERY long topic branch, and they serve as "rebase checkpoints". I rebase those checkpoints in order. So, when I rebase n+1th checkpoint onto the nth checkpoint, I only want to rebase the commits between the original position of the nth checkpoint ($COMMIT2) and current position of n+1th checkpoint ($COMMIT3), and I want to rebase them --onto the current position of the nth checkpoint:

git rebase --onto phpunit-8 origin/phpunit-8 before-reorganize-tests

Which of the two methods you suggested is more appropriate for this scenario?

(Also the word "drop" is scary. Please reassure me that it has nothing to do with the sense of "drop" that is used in DROP TABLE.)

[rulatir]

Also, in strategy № 1 the last command errors out:

usage: git-imerge [-h] {start,merge,rebase,drop,revert,continue,finish,diagram,list,init,record,autofill,simplify,remove,reparent} ...
git-imerge: error: The checked-out branch could not be used as the imerge name.
Please use the --name option.

[rulatir]

Also also, after figuring out that I will need to give a dummy name in the last step of strategy 1, I tried to rebase a "tight" checkpoint that is only one commit after the previous checkpoint. I expect git-imerge to be rebasing exactly one commit in this situation, but it grinds for minutes and writes profusely to standard output:

...
Autofilling 54-43...success.
Autofilling 54-44...success.
Autofilling 54-45...success.
Autofilling 54-46...success.
Autofilling 54-47...success.
Autofilling 54-48...success.
Autofilling 54-49...success.
Autofilling 54-50...success.
Autofilling 54-51...success.
Autofilling 54-52...success.
Autofilling 54-53...success.
Autofilling 54-54...success.
Autofilling 54-55...success.
Autofilling 54-56...success.
Autofilling 54-57...success.
Autofilling 54-58...success.
Autofilling 54-59...success.
Autofilling 54-60...success.
Autofilling 54-61...success.
Autofilling 54-62...success.
Autofilling 54-63...success.
Autofilling 54-64...success.
Autofilling 54-65...success.
Autofilling 54-66...success.
Autofilling 54-67...success.
Autofilling 54-68 (first way)...success.
Autofilling 54-68 (second way)...success.
The two ways of autofilling 54-68 agree.
Recording autofilled block MergeState('chkpt', tip1='before-reorganize-tests', tip2='e4406b621132603555dc02717979a794659845c8', goal='rebase')[30:55,17:69].
Attempting automerge of 54-81...success.
Autofilling 31-81...success.
Autofilling 32-81...success.
Autofilling 33-81...success.
Autofilling 34-81...success.
Autofilling 35-81...success.
Autofilling 36-81...success.
Autofilling 37-81...success.
Autofilling 38-81...success.
Autofilling 39-81...success.
Autofilling 40-81...success.
Autofilling 41-81...success.
Autofilling 42-81...success.
Autofilling 43-81...success.
Autofilling 44-81...success.
Autofilling 45-81...success.
Autofilling 46-81...success.
Autofilling 47-81...success.
Autofilling 48-81...success.
Autofilling 49-81...success.
Autofilling 50-81...success.
Autofilling 51-81...success.
Autofilling 52-81...success.
Autofilling 53-81...success.
Autofilling 54-69...success.
...

... indicating that it is rebasing lots and lots of commits, and that probably the drop command didn't "take" for some reason.

[rulatir]

I don't think there is a confusion as to what git-imerge should do. It all seems to boil down to two sequences of commits forming a X×Y grid, and finding a path through that grid. With regular git, we also have X and Y sequence, except the X sequence is only represented by its head, and the Y sequence commits are cherrypicked onto X sequence's head in order. What I want from git-imerge is the possibility to specify the exact same Y sequences for git-imerge rebase that I can specify with various git rebase usages:

# X = {last common ancestor of HEAD and foo, + all ancestors of foo that aren't ancestors of HEAD, + foo itself}
# Y = {all ancestors of HEAD that aren't ancestors of foo, + HEAD itself}
git rebase foo

# X = {same as above}
# Y = {all commits that are ancestors of HEAD and descendants of origin/foo, plus HEAD itself}
git rebase --onto foo origin/foo

Then I simply want git-imerge to run its rebase algorithm on those sequences.