Reputation: 24441

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

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

Upvotes: 24

Answers (11)

mpasko256

Reputation: 841

What helped in my case: (also improving vinboxx's answer)

I had got configured .gitattributes in a following way:

* text eol=crlf

(I wanted -X renormalize to automatically use proper format after merge)

After temporarily commenting that line along with setting git config core.autocrlf false. Everything went back to normal.

Upvotes: 1

Jan Swiatecki

Reputation: 1

To avoid this problem next time, I decided to convert my file system to case-sensitive.

I was pleasantly surprised that it is pretty easy on Mac OS (10.13.4).

It's possible to create quickly a new disk-volume with a different file system:

run Disk Utility
click on Container
click on Volume (+)

I named new volume "Projects" and set Format to APFS (Case-sensitive).

After that I moved all projects to the new volume.

Upvotes: 0

Igor

Reputation: 34021

For some reason this same thing happened to me, but it was not a case-sensitivity problem. Deleting the file, then changing branches resolved the issue.

Upvotes: 1

vinboxx

Reputation: 685

Did you try

git config --global core.autocrlf false

git config --global core.filemode false

Upvotes: 9

Badal

Reputation: 295

I faced the same problem. I found that the two problematic files had DOS line ending characters. I did this to fix the problem.

1- use a different clone to change the line ending to UNIX 2- blow away the clone where the problem was appearing and re clone it.

Upvotes: 0

Christopher

Reputation: 44304

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.

Upvotes: 6

Highway of Life

Reputation: 24441

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.

Upvotes: 23