summaryrefslogtreecommitdiff
path: root/git-gui/windows
diff options
context:
space:
mode:
authorLibravatar Junio C Hamano <gitster@pobox.com>2012-09-10 16:30:20 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-09-10 18:42:30 -0700
commitffcabccf5df17f12997feedafefeb5589b8c0511 (patch)
treec65351b5cbc06dc78966cf387411887ea8c35373 /git-gui/windows
parentGit 1.7.10.5 (diff)
downloadtgif-ffcabccf5df17f12997feedafefeb5589b8c0511.tar.xz
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>
Diffstat (limited to 'git-gui/windows')
0 files changed, 0 insertions, 0 deletions