Re: Incorrect git-blame result if I use full path to file

[Jeff King <peff@peff.net>]

On Sun, Dec 02, 2007 at 04:52:36PM -0800, Anatol Pomozov wrote:

> I just start learning git and I found a bug (but sorry if the
> functionality I am trying to blame as a bug not actually bug and it
> was made by intention)

Some of both, I think. :)

> It is exaclty what we expect. But lets try full path for master.txt
> $pwd
> /personal/sources/learn/gitea/repo
> $git blame /personal/sources/learn/gitea/repo/master.txt
> ^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 1) On master
> ^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 2) On master
> ^69bce74 (Anatol Pomozov 2007-12-02 16:44:07 -0800 3) On master

We talk about many git commands taking "files" or "paths" but really
they are git "pathspecs", meaning a path specifier that is relative to
the repository root, and which is generally used for limiting the parts
of the history we are looking at.

So I think what is happening is that git-blame is looking for content
from /personal/sources/..., which of course as a git pathspec doesn't
match any of the files. So everything ends up being blamed on
'^69bce74' (which really means "beyond where we started looking"). But
of course it still finds the content to try blaming in the first place,
because in that instance it treats /personal/sources/... as a file to be
opened.

IOW, it's not intended for users to use absolute paths in this way.
However, the results for git-blame are obviously quite confusing. It
might be worth fixing, but I suspect there are many more such traps
waiting in other commands. I wonder if it would make sense to reject
pathspecs starting with '/' entirely, which would at least give us a
saner error message (and I can't think of a time when such a pathspec
would be useful)? Even more useful would be to convert
/path/to/repo/file to 'file' internally.

-Peff