Thomas Rast <[email protected]> writes:
> So (I think?) in the above you claim that $USER interprets
>
> git log -- README.md
>
> as
>
> Show me the history of README.md.
>
> But there's no such thing as the history of a file! The command instead
> says
>
> If I filter all history for only changes affecting a path 'README.md'
> in the root of the repository[1], then what does it look like?
Correct. The "design principle" I did not quote from your message
comes from one of the most important messages in the list archive
($gmane/217).
Three issues with "--follow" are:
(1) It uses the given pathname as single pathspec and drill down
the same way without "--follow" until it notices the path
disappears and until then there is no attempt to detect renames
is made. And it only does -M variant of rename detection
(2) The "same way" in (1) includes the merge simplification to cull
side branches if one parent matches the end result. In a
history where the first parent of a merge M, i.e. M^1, did not
have path F, its second parent M^2 had path F, and the merge
result M deposited the contents of M^2:F at M:D/F, then running
"log --follow F" starting from M would notice that the end
result M did not have F in it, which is shared with its first
parent M^1, and culls the side branch M^2. The --full-history
option may let you keep the history leading to M^2, though.
(3) When (1) notices that the path being followed did not exist in
any of the parents (be it a merge or a non-merge) and finds a
different path with a similar looking content, it _switches_
the pathspec to it, but the single pathspec it uses is a global
state and affects traversals of other ancestry paths at the
same time. Because of this, "--follow" will not work correctly
in a history that contains merges. It often _appears_ to work
only by accident.
The first two are relatively minor (the second is not even an
issue).
To solve the last one, you would need to keep track of which path it
is following per traversal path.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
