Pavel Rappo <pavel.rappo@xxxxxxxxx> writes: > I'm looking for a robust way to determine if a given merge commit > could've been produced automatically by `git merge`, without any > manual intervention or tampering, such as: > > - resolving conflicts, > - stopping (`--no-commit`) and modifying, > - amending the commit. This fundamentally cannot be done perfectly and it is by design. The automated merge algorithms, backends, and strategies will improve over time, so a merge attempted 7 years ago with the then-current version of Git may have conflicted and required manual resolution, but a newer Git you use to "look for manual intervention or tampering" may have improved enough to resolve the same merge cleanly and automatically. Even if the person who created the merge originally and you are using with the same version of Git, the former may be using a custom low-level merge driver to resolve conflicts in certain types of files better than the barebones textual merge driver, while you do not have access to the same driver. So you'd need to tighten the definition a bit more, at bit more like constraints like "using the same version of Git" and "without any low-level merge driver customization". Now, with problem narrowed down a bit with tightened constraints. > My initial idea was to re-enact the merge. If the merge failed, ... > My second idea was to use `git show --diff-merges=dense-combined` ... > My third idea was to use a recently added feature, `git show --remerge-diff`... The first and the third are equivalent (the latter is an automation of what the former would do). The --cc output, as you said, is about showing resolution that is different from any of the parents, and serves the need quite different from what you are trying to do (e.g., if the merge was created with "git merge -s ours", there is nothing _interesting_ in the result from the "--cc"'s point of view), but it is likely that you are interested in noticing such an unusual "cauterizing the history" merge.
