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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
