Re: How to debug a "git merge"?

From: Jeff King <peff@peff.net>
Date: Mar 14, 2018, 22:20 UTC
Message-ID: <20180314222028.GA20977@sigill.intra.peff.net>
In-Reply-To: <7895279B-9FB6-471B-A8BA-53315B265A51@gmail.com>

On Wed, Mar 14, 2018 at 05:56:04PM +0100, Lars Schneider wrote:

Show 17 quoted lines

> 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.

If the wrong file is indeed picked by the merge, then you may want to try switching merge drivers. E.g., "-s resolve" is a bit simpler and stupider than the default merge-recursive. If the problem goes away, then we know it's a possible bug in merge-recursive (or maybe a confusing implication of its strategy). If the problem is still there with "resolve", then at least it may be easier to debug. ;)

-Peff