Reputation: 406
I wanted to that, if given a commit A, and parents B and C, is it possible to know whether or not the attempted merge resulted in a merge-conflict for the end user which the user was required to manually resolve?
(edit: I am looking for a programmatic solution that doesn't rely upon the git toolchain. For example, is there a particular algorithm that I can run on the file contents of commits B and C?)
Upvotes: 0
Views: 214
Reputation:
To answer your direct question, no, Git does not store metadata on whether a merge commit had a manually resolved conflict. You cannot recover that information after the fact except by re-trying the merge. And you're right that whether you'll get a conflict depends on the exact options you pass to git merge
, so you'd need to prompt the user for those options.
I neglected to mention the use case. The github.com/src-d/go-git library seems to have trouble selecting the commits of the history of a particular file.
For that use case, detecting merge conflicts is insufficient.
Suppose you have a file
A
B
C
D
E
F
On branch 1, you change B
to b
.
On branch 2, you change E
to e
.
When you merge the two branches, you won't get a merge conflict, but you will get a version of the file that hadn't existed previously.
I think you should instead declare that a merge commit is relevant for the history of a file if and only if there is no parent commit in which that file has the same contents.
Upvotes: 1