> On 14 Mar 2018, at 23:20, Jeff King <peff@xxxxxxxx> wrote: > > On Wed, Mar 14, 2018 at 05:56:04PM +0100, Lars Schneider wrote: > >> I am investigating a Git merge (a86dd40fe) in which an older version of >> a file won over the newer version. I try to understand why this is the >> case. I can reproduce the merge with the following commands: >> $ git checkout -b test a02fa3303 >> $ GIT_MERGE_VERBOSITY=5 git merge --verbose c1b82995c >> >> The merge actually generates a merge conflict but not for my >> problematic file. The common ancestor of the two parents (merge base) >> is b91161554. >> >> The merge graph is not pretty (the committers don't have a clean >> branching scheme) but I cannot spot a problem between the merge commit >> and the common ancestor: >> $ git log --graph --oneline a86dd40fe >> >> Can you give me a hint how to debug this merge further? How can I >> understand why Git picked a certain version of a file in a merge? > > Maybe a stupid question, but: did you make sure that the merge does > indeed pick the wrong version of the file? The other option is that > somebody mistakenly did a "checkout --ours" or similar while resolving > the conflict. No stupid question at all. That's exactly what they did and I did not realize it! Thank you! Next time I won't stumble over this. I wonder if this is a common enough problem to do something about it? For instance what if `git log` (or just `git show`) has an option `--verify-merges` or `--reenact-merges` or something? This option would perform a "default recursive merge" and show the diff between the actual merge and the default merge? In the most common case there is no diff. If there are merge conflicts then we would just show the conflicting files. If there is no merge conflict for a file *but* a difference then we would show it. I think this would have helped me to realize this kind of problem earlier. Would that option make sense to you? Thanks, Lars
