Is it possible to identify merge commits that had conflicts after the fact?

Question

I am trying to collect a dataset of merge conflicts based on programmatic command line interactions. The program should run in the terminal, I am fine with using external tools as long as they are also permissive and or cheap.

The heuristic I am using right now is to collect merge commits where at least one file has the status of 'MM' when running git show commit --name-status. Based on my understanding, this should indicate that the file was modified during the merge.

I have realized, however, that 'MM' can also occur simply due to the merge strategy that git uses and is not sufficient for identifying the subset of commits that actually contain a conflict.

I could simply try to merge the parents for every such commit to find conflicts, but that seems quite costly and tedious and I feel like there has to be a better solution. Is there a more convenient way than trial-and-error to retrospectively identify merge commits during the creation of which conflicts occurred in git? Furthermore, I would also be interested in doing the same for cherry-picks if possible.

Answer 1

There is a method that is more convenient, but not necessarily less costly.

You can investigate a merge commit with

git show --remerge-diff <commit>

and if the output does not show any conflict markers, the automatic merge did not find conflicts. However, to be sure that the merge commit recorded the result of the automatic merge there must not be any diff output at all. (If the commit is an "evil merge", additional changes were introduced that would show up in the diff output.)

Doing the same for cherry-picked commits is impossible. You have to repeat the cherry-pick to know whether there were conflicts or not.