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
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