How to prevent git doing a fast-forward when rebasing a branch that's been merged, then reverted

user_187581 0
Viewed 141

I have a branch called feature which branches off main at commit F, with two commits, A and B.

This was merged with a merge commit, M, and then the merged was reverted with commit R.

I now want to rebase branch feature so it's on the tip of main, with its commits A and B again, (so I can carry on working on it and fix the problem that caused the revert to be needed).

However, when I do git rebase main, git just fast-forwards me to the tip of main, presumably because it sees that A and B are already on main.

How do I force this?

I've tried git rebase --onto main SHA_FOR_F --no-ff but that does the same thing.

Here's the situation:

R - main
|
M
|\
| B - feature
| |
| A
|/
F
|

and I'd like:

B - feature
|
A
|
R - main
|
M
|\
| B
| |
| A
|/
F
|

I know I could just cherry-pick A and B individually, but is there a way of doing this in one go?

git
1 Answers

(if you only have 2 commits, cherry-picking by hand is obviously a very viable option)

You can also pass a range to git cherry-pick :

git cherry-pick F..B

This will skip the "detect if a commit is already part of target branch" algorithm which git rebase does.

[edit]

actually, git rebase also has an option to skip this check : --reapply-cherry-picks (added in v2.27, Q2 2020)

git rebase --reapply-cherry-picks --onto master F B

the advantage being you can also add --interactive, and edit yourself what should and shouldn't be kept.

user_860720
Related