git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: How to debug a "git merge"?

From
Derrick Stolee <stolee@gmail.com>
Date
Mar 20, 2018, 01:32 UTC
Message-ID
<b852dc0d-f601-f36a-c996-b3395a3cb3fd@gmail.com>
In-Reply-To
<77D50EDA-6262-4288-B6E7-87BE63EFB54F@gmail.com>
On 3/14/2018 4:53 PM, Lars Schneider wrote:
Show 56 quoted lines
>> 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

Previous: Lars SchneiderNext: Jeff King
Message 4 of 8 in “How to debug a "git merge"?”
  1. Lars SchneiderMar 14, 2018
  2. Derrick StoleeMar 14, 2018
  3. Lars SchneiderMar 14, 2018
  4. Derrick StoleeMar 20, 2018
  5. Jeff KingMar 14, 2018
  6. Lars SchneiderMar 15, 2018
  7. Jeff KingMar 15, 2018
  8. Elijah NewrenMar 15, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.