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