3

I branched off of master a month ago and worked on a big project. Then I merged it back to master. No surprise, there were merge conflicts. I resolved them and committed the merge. Now a few days later I am testing some code and I found some changes that had been made on master that are gone. Question: did I mess up my conflict resolution, or did git automatically merge out that change? To put the question another way, is there a way in git to look at a merge commit and know which files had conflicts and how they were resolved?

Picture of what I'm talking about. (I'm visual)

|
+ <-------------------------+ Merge back to master
|                           |
+ -- Change that got lost   +
|                           |
+-------------------------> + My branch
|
master

git show merge-commit-id is not doing it for me. I am using Visual Studio with git in Team Explorer. I can plainly see that the code was lost (in red) in the merge commit, but I don't know if it was a conflict resolution or automatic git merge. The reason I'm asking is because I have many other changes on master that I want to make sure are still there. Thank you.

(I could revert the merge commit and do it again, but there would be many conflicts to resolve again... is that my only option?)

Jess
  • 23,901
  • 21
  • 124
  • 145
  • Wow. Looking at this question from so long ago, I think a better answer now is to use a better git workflow like... gitflow! I don't have big merge conflicts anymore. – Jess Jan 19 '22 at 16:28
  • With Git 2.36 (Q2 2022), `git log --remerge-diff` could have helped you and show you what was done in a past merge resolution! See [my answer to this other question](https://stackoverflow.com/a/71181334/6309). – VonC Feb 19 '22 at 00:33

1 Answers1

1

As you suggest, re-running the merge is your best bet. However you don't have to revert it, you can just repeat it using a temporary branch. If $M is the merge commit, then:

$ git checkout -b merge-redo ${M}^1
$ git merge ${M}^2

That is, create a new branch pointing to the first parent of the merge commit, then merge in the second parent. Note that you'll need to use the same -s (merge strategy) and/or -X (strategy option) options as were used in the original merge in order to get exactly the same conflicts.

At this point, git status shows the files in conflict and git log --merge and git log --merge -- <files> can be used to see the commits that contributed to the conflicts.

If you know that some files were resolved correctly, you can take their resolutions from the original merge conflict like this:

$ git checkout $M -- <files ...>
$ git add <files ...>

This can help to cut down on the mental load involved in understanding a large merge.

Matt McHenry
  • 20,009
  • 8
  • 65
  • 64