Re: How to debug a "git merge"?

[Derrick Stolee <stolee@gmail.com>]

On 3/14/2018 4:53 PM, Lars Schneider wrote:
>> On 14 Mar 2018, at 18:02, Derrick Stolee <stolee@gmail.com> wrote:
>>
>> On 3/14/2018 12:56 PM, Lars Schneider wrote:
>>> Hi,
>>>
>>> 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
>> Have you tried `git log --graph --oneline --simplify-merges -- path` to see what changes and merges involved the file? I find that view to be very helpful (while the default history simplification can hide things). In particular, if there was a change that was reverted in one side and not another, we could find out.
> Thanks for this tip! Unfortunately, this only confirms my current view:
>
> ### First parent
> $ git log --graph --oneline --simplify-merges a02fa3303 -- path/to/problem
> * 4e47a10c7 <-- old version
> * 01f01f61c
>
> ### Second parent
> $ git log --graph --oneline --simplify-merges c1b82995c -- path/to/problem
> * 590e52ed1 <-- new version
> * 8e598828d
> * ad4e9034b
> * 4e47a10c7
> * 01f01f61c
>
> ### Merge
> $ git log --graph --oneline --simplify-merges a86dd40fe -- path/to/problem
> *   a86dd40fe <-- old version ?!?! That's the problem!
> |\
> | * 590e52ed1 <-- new version
> | * 8e598828d
> | * ad4e9034b
> |/
> * 4e47a10c7 <-- old version
> * 01f01f61c
>
>
>> You could also use the "A...B" to check your two commits for merging, and maybe add "--boundary".
> $ git diff --boundary a02fa3303...c1b82995c -- path/to/problem
>
> This looks like the correct diff. The "new version" is mark as +/add/green in the diff.
>
> Does this make any sense to you?
>
> Thank you,
> Lars

I'm sorry for the delay on this, but in my experience in helping 
customers saying "why doesn't my commit/change appear in the history of 
a file?" is because someone resolved merge conflicts by just taking one 
side instead of doing a real merge (such as using -Xours). The only 
solution is to re-apply the original change again and talk to the user 
who incorrectly merged, to prevent future occurrences. These things 
rarely happen to teams who use pull requests that require review, since 
the diff would be problematic. There are still a lot of teams that push 
directly to master, though.

Thanks,
-Stolee