Re: [PATCH] t4202 (log): add failing test for log with subtree

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Apr 22, 2013, 12:29 UTC
Message-ID: <CALkWK0nMgbZY7E-wPNj2C7W98Y4HtQ7Hss6uMKngajB5iJrjDw@mail.gmail.com>
In-Reply-To: <vpqa9oqpxx7.fsf@grenoble-inp.fr>

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.