Matthieu Moy wrote: > This is somehow expected: the subtree merge changed the filename during > merge (it is subtree/file.txt after the merge, and just file.txt > before), so "git log" without --follow just considers the file appeared.
No, a merge does not "change" any filenames. The history of the file is very much present: run a git log HEAD^2 to see the entire history of the subtree. Even a git blame (without -M or -C) works just fine. > OTOH, I think this is a known limitation of "git log --follow" that it > does not follow renames done by subtree merges. Um, no. I think --follow is entirely orthogonal to the issue: unless I'm mistaken, it looks for other blobs in history with heuristically similar content. The real issue has nothing to do with log itself: it has to do with how rev-parse handles pathspecs. A 'git rev-parse HEAD:subproject/README' works fine, but 'git rev-parse HEAD^2:subproject/README' fails. However, 'git rev-parse HEAD^2:README' works, but it is assuming that the path README is present in /, when it is actually present in subproject/. Now, I'm not sure rev-parse is doing something unexpected, which is why I filed the bug in log. -- 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
