Junio C Hamano wrote:
> [...]
>  (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.

This explanation is all very nice, but isn't it completely tangential
to the issue at hand?

Let's say I have a subtree merge M located at HEAD~4.  I ask for the
log of 'HEAD~4 -- README' with --follow.  It follows until it gets to
M: at M, M^1:README is missing, but M^2:README is present.  Should it
follow down and show the history of M^2:README?

You can reserve the discussion about --follow working in the general
case for another thread.  Meanwhile, you're evading the issue of
assuming that all trees are read into /, and are really representing
the same project's history, while this is not the case.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to