If a file's history includes a merge commit with an "interesting" conflict resolution, git log
will skip over it. Why is this, and how can I make that commit be included?
(By "interesting", I mean a resolution that doesn't just take the version from HEAD
or MERGE_HEAD
verbatim.)
For example, in this sample repository, I've prepared a simple history that illustrates the problem:
$ git log --oneline --graph
* 4a69f452 add -stuff at C and G
* 9fc8e8bf resolve E-alpha + E-beta as E-gamma
|\
| * 95bc62e9 add -beta suffix on lines E and J
* | 465abd9e add -alpha suffix on lines A and E
|/
* f43dc68c initial ten-line A..J file
The merge commit resolved the conflict by introducing an entirely new version of the E
line:
$ git show 9fc8e8bf -U0 | grep -A100 ^@@
@@@ -5,1 -5,1 +5,1 @@@
- E-alpha
-E-beta
++E-gamma
However, git log
totally glosses over this. The commits it lists fail to explain the current state of the E
line in test.txt
:
$ git log --oneline 4a69f452 test.txt
4a69f452 add -stuff at C and G
95bc62e9 add -beta suffix on lines E and J
465abd9e add -alpha suffix on lines A and E
f43dc68c initial ten-line A..J file
Is there an option I can give to git log
that will make it include the merge commit?
Other commands, like git blame
, do show that the E
line was last touched in the 9fc...
merge commit:
$ git blame -L5,5 4a69f452 test.txt
9fc8e8bf9 (Matt McHenry 2016-12-28 16:55:10 -0500 5) E-gamma
(Note: the above outputs are produced by git version 2.11.0
.)
This happens if you have the
log.follow
config option set totrue
or, equivalently, if you pass--follow
to the log command.The documentation for this option says it "does not work well on non-linear history". I guess this is what they mean. :(