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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html