0

I need to rescue a feature branch which got some duplicated commits due to a rebase fail. Currently the only way to fix it is to cherry-pick all commits off this feature branch into master (see background below).

We started with the most recent state of master and then started cherry-picking our feature-branch commits. However we sometimes merged master into our feature branch and I'm unsure if I also need to cherry-pick those merge commits. I think not, because I already resolved the conflicts when cherry-picking into the current master. Is that correct?

PS: Background

We discovered the duplicated commits too late and the feature branch already has 100 more commits on top. Due to our CI structure we can't just revert the duplicate commits. Our first try at rescuing was to rebase and just ommit the duplicate commits. This does not work as it changes revision ids of some commits which are not part of our feature branch (we can't change revison ids of commits already in master!). Therefore our current mode of rescue is to just cherry-pick all changes in this feature branch into master.

cgross
  • 1,932
  • 2
  • 15
  • 20

1 Answers1

1

Maybe you should rebase your feature branch onto the latest master branch, fixing all weirdnesses instead?

If not, then yes, you are right. When you do the same conflict resolution when cherry-picking the commits from the feature branch to master that you did when merging master into the feature branch, you should not need to pick the merge commits. Actually if you do merge the merge commit, I'd exepect you end up with no changes as you should have solved the conflicts properly already. You cannot cherry-pick a merge commit anyway without giving the mainline with -m manually anyway.

Vampire
  • 35,631
  • 4
  • 76
  • 102