git blame --reverse: it's all a bit mysterious

git blame --reverse: it's all a bit mysterious

[Robin Green]

The --reverse option to git blame (which isn't listed in the option summary when you type just "git blame",
but *is* listed in the cross-referenced git-rev-list(1), though that's not terribly helpful) doesn't seem
to understand what I'm trying to ask, and the man page is not much help.

greenrd@cspcnh /var/db/paludis/repositories/arbor $ strace -f -e trace=file git blame --reverse 48d96ce0e486eedea9fda0f8e480ba3c6caffc90..HEAD exlibs/eutils.exlib
execve("/usr/bin/git", ["git", "blame", "--reverse", "48d96ce0e486eedea9fda0f8e480ba3c"..., "exlibs/eutils.exlib"], [/* 41 vars */]) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/usr/lib/libz.so.1", O_RDONLY)    = 3
open("/usr/lib/libcrypto.so.0.9.8", O_RDONLY) = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/lib/libdl.so.2", O_RDONLY)       = 3
getcwd("/var/db/paludis/repositories/arbor", 4096) = 35
stat64(".", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(".git/objects", X_OK)            = 0
access(".git/refs", X_OK)               = 0
lstat64(".git/HEAD", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
open(".git/HEAD", O_RDONLY|O_LARGEFILE) = 3
access("/etc/gitconfig", R_OK)          = 0
open("/etc/gitconfig", O_RDONLY|O_LARGEFILE) = 3
access("/home/greenrd/.gitconfig", R_OK) = 0
open("/home/greenrd/.gitconfig", O_RDONLY|O_LARGEFILE) = 3
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access(".git/config", R_OK)             = 0
open(".git/config", O_RDONLY|O_LARGEFILE) = 3
access("/etc/gitconfig", R_OK)          = 0
open("/etc/gitconfig", O_RDONLY|O_LARGEFILE) = 3
access("/home/greenrd/.gitconfig", R_OK) = 0
open("/home/greenrd/.gitconfig", O_RDONLY|O_LARGEFILE) = 3
access(".git/config", R_OK)             = 0
open(".git/config", O_RDONLY|O_LARGEFILE) = 3
access("/etc/gitconfig", R_OK)          = 0
open("/etc/gitconfig", O_RDONLY|O_LARGEFILE) = 3
access("/home/greenrd/.gitconfig", R_OK) = 0
open("/home/greenrd/.gitconfig", O_RDONLY|O_LARGEFILE) = 3
access(".git/config", R_OK)             = 0
open(".git/config", O_RDONLY|O_LARGEFILE) = 3
lstat64("exlibs/eutils.exlib", 0xbf896768) = -1 ENOENT (No such file or directory)
stat64(".git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getcwd("/var/db/paludis/repositories/arbor", 1024) = 35
chdir(".git")                           = 0
getcwd("/var/db/paludis/repositories/arbor/.git", 4096) = 40
lstat64("/var/db/paludis/repositories/arbor/.git", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
chdir("/var/db/paludis/repositories/arbor") = 0
chdir("/var/db/paludis/repositories/arbor") = 0
lstat64("48d96ce0e486eedea9fda0f8e480ba3c6caffc90..HEAD", 0xbf896768) = -1 ENOENT (No such file or directory)
fatal: cannot stat path '48d96ce0e486eedea9fda0f8e480ba3c6caffc90..HEAD': No such file or directory

Now this error message is very unhelpful. Why is git blame trying to interpret this as a filename,
when the man page implies that it expects a revision range (or possibly a single revision, if you
believe the option summary at the top of the man page)?

This isn't the first time I've noticed git misinterpreting a revision (range) as a filename, but
in this case, I have no clue what is going on.

I notice from the strace output that it's looking for the specified filename first, which of course
no longer exists in HEAD. The man page implies that blame --reverse only needs the file to exist
in the first revision of the revision range; if it also needs to exist in the *working tree* or
something like that, that should be documented in the man page.

I'm using git version 1.7.3.2.
-- 
Robin Green

Re: git blame --reverse: it's all a bit mysterious

[Thomas Rast]

Robin Green wrote:
> greenrd@cspcnh /var/db/paludis/repositories/arbor $ strace -f -e trace=file git blame --reverse 48d96ce0e486eedea9fda0f8e480ba3c6caffc90..HEAD exlibs/eutils.exlib
[...]
> I notice from the strace output that it's looking for the specified filename first, which of course
> no longer exists in HEAD.

This can be fixed by saying

  git blame --reverse 48d96ce0e486eedea9fda0f8e480ba3c6caffc90..HEAD -- exlibs/eutils.exlib

i.e., you need to supply the -- to explicitly tell it that the stuff
after it is a filename.

It's probably a code (not documentation) bug since blame takes only a
single revision range anyway, so everything after that should be
assumed to be a filename, but maybe I'm missing something.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch