blame $path: avoid getting fooled by case insensitive filesystems
authorJunio C Hamano <gitster@pobox.com>
Mon, 10 Sep 2012 23:30:20 +0000 (16:30 -0700)
committerJunio C Hamano <gitster@pobox.com>
Tue, 11 Sep 2012 01:42:30 +0000 (18:42 -0700)
commitffcabccf5df17f12997feedafefeb5589b8c0511
treec65351b5cbc06dc78966cf387411887ea8c35373
parent785ee4960c3d334cbc2b17ab74d2cebdf1b4db64
blame $path: avoid getting fooled by case insensitive filesystems

"git blame MAKEFILE" run in a history that has "Makefile" but not
MAKEFILE can get confused on a case insensitive filesystem, because
the check we run to see if there is a corresponding file in the
working tree with lstat("MAKEFILE") succeeds.  In addition to that
check, we have to make sure that the given path also exists in the
commit we start digging history from (i.e. "HEAD").

Note that this reveals the breakage in a test added in cd8ae20
(git-blame shouldn't crash if run in an unmerged tree, 2007-10-18),
which expects the entire merge-in-progress path to be blamed to the
working tree when it did not exist in our tree.  As it is clear in
the log message of that commit, the old breakage was that it was
causing an internal error and the fix was about avoiding it.

Just check that the command does not die an uncontrolled death.  For
this particular case, the blame should fail, as the history for the
file in that contents has not been committed yet at the point in the
test.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/blame.c
t/t8004-blame-with-conflicts.sh