1

I am rebasing a complex feature to another branch using git cherry-pick. When trying to resolve conflicts in a big commit, I find out that I've missed some other commit that should be applied first.

I can't stash the current state, apply the other commit and then do stash pop.
I could do cherry-pick --abort, apply the other commit and then cherry-pick it again, but I would lose those resolved conflicts.

What is the best way to deal with such situation?

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
Radim Vansa
  • 5,686
  • 2
  • 25
  • 40
  • Is it "should be" or "must be"? If the former, continue, then rectify the situation when you have committed the resolution. – j6t Dec 15 '16 at 14:16
  • The missed commit already deals with some of the conflicts, I wouldn't have to deal with them manually. – Radim Vansa Dec 19 '16 at 12:36
  • I've done big conflicting merges in the past, and in the same situation as you describe. I bit the bullet and complete the merge. Then rewound, applied the helpful other commit, then redid the merge. Fortunately, the `rerere` machinery resolves many of the commits again automatically. – j6t Dec 19 '16 at 18:51

1 Answers1

1

Following j6t advice, you can complete then rewind, apply the other commits and cherry-pick again.

The idea is to make sure git rerere is active in order to avoid resolving the merge conflicts all over again.

If you did not activated rerere, you have the rerere-train.sh script I mentioned before, in order to not forget your conflict resolution of your first round of merges.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250