Is there a less cumbersome way to do this rebase?

Question

I sometimes find myself in the situation below and want to rebase C onto B:

       B
     /
   A
     \
       C <-- HEAD

I find that if I simply do git rebase B, I often get lots of warnings about "falling back to merge strategy" and "automatically resolving" conflicts. Sometimes I straight up get a conflict.

So what I've taken to doing instead is git rebase A --onto B. This almost always succeeds with no warnings or conflicts.

I don't really understand the difference between these 2 commands and why the first one is more problematic. Is there a less cumbersome way to do what I want without having to specify 2 different commits?

(for example: git rebase --some-magic-switch B)?

EDIT: Just for added clarity, the desired result is:

A -- B -- C' <-- HEAD

Both git rebase B and git rebase A --onto B get me to the desired result. The only difference is that the first one produces warnings and sometimes conflicts.

Does this answer your question? [Difference between 'rebase master' and 'rebase --onto master' from a branch derived from a branch of master](https://stackoverflow.com/questions/33942588/difference-between-rebase-master-and-rebase-onto-master-from-a-branch-deri) — samthegolden, Mar 13 '20 at 19:21
Does this answer you? https://stackoverflow.com/questions/33942588/difference-between-rebase-master-and-rebase-onto-master-from-a-branch-deri — samthegolden, Mar 13 '20 at 19:21
`git rebase B` is exactly the right command to go from the pictured initial state to the desired final state. — mkrieger1, Mar 13 '20 at 19:34
@mkrieger1 Both of the commands go the same desired state... but the simpler one often produces warnings — JoelFan, Mar 13 '20 at 20:04
If your history graph looks like shown, both commands should be absolutely identical. Not sure why there would be more conflicts. Can you provide a [mre] with the required steps? — knittl, Oct 21 '22 at 15:51

score 0 · Answer 1 · answered Oct 24 '22 at 10:27

There shouldn't be any warnings or conflicts, but if you want to be really explicit:

git rebase --onto B A C

This will take all commits in the range A..C and copies them on top of B.

Of course, conflicts can still occur if there are actual conflicts, e.g. C changes the same lines that B changed.

Is there a less cumbersome way to do this rebase?

1 Answers1