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
More majordomo info at

Reply via email to