Ramkumar Ramachandra [off-list ref] writes:
was checking it out: a 'git log <pathspec>', when referring to a file
inside the subtree, doesn't work as expected: it only displays the
HEAD commit.
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.
OTOH, I think this is a known limitation of "git log --follow" that it
does not follow renames done by subtree merges.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
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.