git checkout -- <files> doesn't discard changes?

Question

I have changes in my working directory that I'm trying to discard (reset to the current indexed version of the files), however, git checkout -- <file> will not discard the changes. I've attempted to manually remove the files (rm -r files) then run git checkout -- ., which displays the files as modified again.

$ git checkout -- .
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   files/Hulk.png
#   modified:   files/Hulk_2.png
#
no changes added to commit (use "git add" and/or "git commit -a")

Running git diff shows the files are modified...

diff --git a/files/Hulk.png b/files/Hulk.png
index 1c256cb..1d37fe0 100644
Binary files a/files/Hulk.png and b/files/Hulk.png differ
diff --git a/files/Hulk_2.png b/files/Hulk_2.png
index 1c256cb..0717199 100644
Binary files a/files/Hulk_2.png and b/files/Hulk_2.png differ

NOTE: Some people have said to run git checkout ., however this will achieve the same result as git checkout -- .. The -- is just a notation used in the git checkout command to differentiate treeish/commit points from files/paths.

OS: OSX 10.6 Git: 1.7.10.2

Answer 1

The cause for this was due to multiple files with the same name but different cases. In OSX, which is case-insensitive, doesn't like multiple files with the same name but different cases. It views them as the same file. To fix this, I ran git mv (or just mv) to a temporary filename, added the temp files, which allowed git to remove the old/incorrectly named versions, then a second commit to name them back. This could also be corrected on a filesystem which allows different files with the same name to be different cases.

Answer 2

Did you try

git config --global core.autocrlf false

or

git config --global core.filemode false

Answer 3

Based on your comments, you must configure your repository to be case sensitive:

git config core.ignorecase false

This allows git to track both files (although the file system only shows one, which is enormously confusing). Here are replication steps to demonstrate what's happening, when git is correctly tracking case sensitivity:

git init /tmp/test && cd /tmp/test
git config core.ignorecase false
echo test>test && git add test && git commit -m "lowercase t"
mv test Test

Now git status shows no differences to test:

git status -s
 ?? Test

Commit Test and use git ls-files to see what we're now tracking:

git add Test && git commit -m "uppercase T"
git ls-files
 Test
 test

What does ls report? Why, just 'Test', naturally:

ls
 Test

Finally, what happens when we modify Test?

echo garbage>Test
git status -s
 M Test
 M test

What a mess.