Question

I’m working with a repository where a merge was performed weeks ago which we just discovered used the --strategy=ours flag (it was supposed to use the –strategy-option=ours flag), thus not applying any changes to HEAD. However, we need to have the changes applied. Git already recognizes the branch as being merged and the commits in the history of the branch.

This sort of merge can’t be reverted using git revert -m ...

What would be the proper way of reverting and/or re-applying the merge to change the files?

master  A - B - E - F - G ---> L - M - N
             \     /
topic         C - D

Merge commit (F) would be the culprit in this scenario.

Answer 1

I have discovered a solution to this problem. It was all in the letter that Linus wrote regarding reverting faulty merges: How to revert a faulty merge.
The git merge --strategy=ours topic in our case was not intended. Even though it’s a faulty merge, it can’t be reverted, and having long been pushed, has the same effect of having a revert merge commit without being able to revert the revert commit.

The solution was to checkout the topic branch, run rebase --no-ff from the first commit and then merge that branch back into master.

git checkout topic
git rebase -i --no-ff <C>
git checkout master
git merge topic

This had the effect of yielding:

fixed–topic   C'–––D'––––––––––––––––––––-
             /                            \
master  A–––B–––E–––F–––G –––> L–––M–––N–––F2
             \     /
topic         C–––D

To really understand this in-depth, read the last portion of the letter How to Revert a Faulty Merge using the --no-ff rebase option to re-create the branch.