Jeff King [off-list ref] 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).
On Wed, Mar 23, 2011 at 09:58:11AM -0700, Junio C Hamano wrote:
Jeff King [off-list ref] writes:
quoted
# Now try it with --follow. Not so pretty.
git log --oneline --graph --follow builtin/add.c
Is that an artifact of history simplification?
I think it's a combination of factors. The lack of history
simplification is why the graph is all choppy. The insanely wide
results, though, are probably due to the problem you mention below.
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).
When I prototyped the multi-file --follow last summer, I added newly
found source paths to the pathspec list instead of replacing them.
Strictly speaking, this can add unwanted commits when the names are
re-used for unrelated files (either the source name is used on a
parallel side branch, or the destination name is used in an earlier
file). But in practice it generates pretty good results, because those
corner cases don't tend to happen much.
Obviously a solution that always provides an exact right answer is
preferable to "pretty good results", but we'd have to keep in mind the
performance difference.
-Peff