On 3/14/2018 4:53 PM, Lars Schneider wrote:
On 14 Mar 2018, at 18:02, Derrick Stolee <sto...@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
