1

I have 2 branches : A and B. Both started from the same parent branch : C, and then had some changes made in parallel to each of them. I wanted to merge B to A, and tried merging directly from Gitlab. Because both branches modified the same file I had a merge conflict. Gitlab suggested merging also A to B to solve the conflict (I think) and by mistake I clicked that too. I ended up pushing the file that was in a bad state to both branches.

To fix this, I reverted the bad commits for both branches and pushed the revert commits. (git revert -m 1 <commit-hash>) Now the branches look ok in terms of the code they contain.

The problem is that now when I try to merge again B to A (git checkout A git merge B), the changes that were done in B are not added. Only the modifications done in A are removed (the merge conflict is still there though). Something similar happens when trying to rebase, the modifications are removed from B, not added.

Is this because I already merged once and then reverted the commits and now the modifications are no longer considered new?

How can I solve this so I can merge B to A?

Thanks.

Jan Der
  • 11
  • 1
  • Yes, it's because the existing merge is in the history. Since then, the revert of the merge is in the history as well. This leads Git to conclude that the correct result of merging again is to *not* use any of what you want used. – torek Apr 13 '20 at 08:45

0 Answers0