Jeff King <peff@xxxxxxxx> writes:
> # Now try it with --follow. Not so pretty.
> git log --oneline --graph --follow builtin/add.c
Is that an artifact of history simplification?
I've always thought that it was because --follow hack used a single global
pathspec that flipped at a rename boundary,regardless of which part of the
history (i.e. the branch that was before the rename or after the rename)
it is following. So if you have two branches merged together:
o---o---o---o---o---x---x---x
/ /
...o---o---o---x---x---x
where commits marked with 'x' has it under the new path while commits
marked with 'o' has it under the old path, and start to dig the history
from the rightmost commit, the hack notices the rename at the transition
between the "o---x" on the upper branch and from then on keep digging the
history using the old path as the pathspec. The commit history traversal
goes reverse-chronologically, so when inspecting the next commit, which is
the rightmost commit on the lower branch, the hack fails because it uses a
wrong pathspec (at that point it should still be using the new path as the
pathspec, but it already has switched to the old path).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html