git status shows modifications, git checkout -- <file> doesn't remove them

Question

I would like to remove all changes to my working copy.
Running git status shows files modified.
Nothing I do seems to remove these modifications.
E.g.:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Corky

Not sure why the git reset --hard didn't work here. Note: it should be git checkout -- `git ls-files -m` to cancel the files (--) – Repine

If you delete the files and use checkout -- <file> it should work. The change detection is a bit picky in some situations (among others if CRLF mismatch is present) – Astronaut

Possible duplicate of Can't seem to discard changes in Git – Headsail

@Headsail - it is a duplicate, and older and would therefore take precedence. But while the question you link to is essentially the same, the answer I accepted below is much more informative than any of the answers there, and solved my problem. – Corky

not a solution, but a swiss knife for boring case : git update-index --assume-unchaged forces the unchaged state of the files (even for the changed ones!) – Cellaret

Answer 1

There are multiple problems that can cause this behaviour:

Line ending normalization

I've had these kinds of problems too. It comes down to git automatically converting crlf to lf. This is typically caused by mixed line endings in a single file. The file gets normalized in the index, but when git then denormalizes it again to diff it against the file in the working tree, the result is different.

But if you want to fix this, you should disable core.autocrlf, change all line endings to lf, and then enable it again. Or you can disable it altogether by doing:

git config --global core.autocrlf false

Instead of core.autocrlf, you can also consider using .gitattributes files. This way, you can make sure everyone using the repo uses the same normalization rules, preventing mixed line endings getting into the repository.

Also consider setting core.safecrlf to warn if you want git to warn you when a non-reversible normalization would be performed.

The git manpages say this:

CRLF conversion bears a slight chance of corrupting data. autocrlf=true will convert CRLF to LF during commit and LF to CRLF during checkout. A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git. For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository. But for binary files that are accidentally classified as text the conversion can corrupt data.

Case-insensitive file systems

On case-insensitive filesystems, when the same filename with different casing is in the repository, git tries to checkout both, but only one ends up on the file system. When git tries to compare the second one, it would compare it to the wrong file.

The solution would either be switching to a non-case insensitive filesystem, but this in most cases is not feasible or renaming and committing one of the files on another filesystem.

Centrum

Okay... so that did it... now git status shows no changes. I've read up on the autocrlf settings, and I just can't seem to get it right. – Corky

Good catch! +1. Yet another argument for me setting that to false (#1250432). – Repine

What does this mean: "A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git." Is this because git will always normalize line endings, based on the core.autocrlf setting? – Corky

@Corky Indeed. If core.autocrlf is set to auto, when pulling it converts all line endings to crlf, and when pushing, to lf. – Centrum

It should be noted that the quoted passage is from the docs on the core.safecrlf setting, which fixes the mentioned problem. – Gillead

@Ikke, same problem, but your solution didn't work for some reason. Running win8.1, Git-1.9.2-preview. Double checked the .gitconfig file. Also have SourceTree and SmartGitHg installed which weren't running when I used Git Bash – Deepfry

@geotavros Check for a .gitattributes, that can cause it too. – Centrum

@Ikke, thx. That helped to remove one file from 'modified' state. But the other one still remains there. I tried every single answer in this thread, and nothing worked. Must be some bug or some setting. I give up, just spent too much time on this. Will commit it and forget – Deepfry

A more sane solution to the case sensitivity problem is not to have multiple folders in your repo whose names only differ by case. – Blum

To find names of files that differ only by the letter case, you can run git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d. To list both upper and lower case names of such files run git ls-tree -r --name-only HEAD | fgrep -i -f <(git ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d) | sort -i – Desmoid

👏🏻 for pointing out about the case insensitive name conflict – Piece

Answer 2

I was having this problem on Windows but wasn't prepared to look into the ramifications of using config --global core.autocrlf false I also wasn't prepared to abandon other private branches and goodies in my stash and start with a fresh clone. I just need to get something done. Now.

This worked for me, on the idea that you let git rewrite your working directory completely:

git rm --cached -r .
git reset --hard

(Note that running just git reset --hard wasn't good enough nor was a plain rm on the files before the reset as are suggested in the comments to the original question)

Numskull

Another success here after changing core.autocrlf didn't have any effect. – Shortie

Was having this problem on Windows even with core.autocrlf false. This answer worked when nothing else would. – Venola

Mind the period "." at the end of__git rm --cached -r .__ – Brnaby

I have tried multiple suggestions from this and other questions. This is the only fix that worked for me. I had no attribute file and I already started with core.autocrlf at false. – Chilson

This did not work for me. So, I did in more uglier fashion by creating a new branch just to commit these changes as they are useless for me anyways. [java]git checkout -b a-branch-to-commit-bad-crlf-files[/java] [java]git commit -am"committing the bad crlf files"[/java] – Upspring

It wasn't sufficient for me, I had to start anew with git clone to have a clean copy as stated by Fam Wired – Coryphaeus

Sometimes problems like this make me really miss SVN. – Polack

This fixed my issues. I only seem to have them on windows. Basically I can call git checkout on a file with mods and it won't reset. These commands handle the issue and get me back to master. Yay. – Forfar

This is the real solution. One should not need to turn off features to get around git glitches. To be fair, one should not need resets either, but at least that doesn't disable things permanently. – Antonetteantoni

+1 from me..... This should be real solution. After trying out other suggestions this one worked. Thanks – Shipworm

No thanks, you ruined up my project files... – Babiche

git rm --cached -r was not a valid git bash command for me. I had to do git rm . --cached -r (with a dot) – Lucerne

doesn't work for me ... I tried all the other answers also, not sure what keeps them zombie changes in place. – Hufuf

Answer 3

Another solution that may work for people, since none of the text options worked for me:

1. Replace the content of .gitattributes with a single line: * binary. This tells git to treat every file as a binary file that it can't do anything with.
2. Check that message for the offending files is gone; if it's not you can git checkout -- <files> to restore them to the repository version
3. git checkout -- .gitattributes to restore the .gitattributes file to its initial state
4. Check that the files are still not marked as changed.

Inodorous

I've been stuck on not being able to revert, pull, or stash files for the last couple hours. THIS was the fix for me! Thanks! (Git 1.8.3.1) – Kawai

I tried many things before finally finding success with this. Thank you! – Thoma

How does this work? I would think reverting .gitattributes back to original would reintroduce the same issue, but alas my problem is now solved. None of the other suggestions worked in my case. – Footstalk

@jdk1.0 my understanding/guess is that two different comparison methods are involved. The error happens when you have a differing line ending somewhere, and git sometimes ignores it. When you ask git status, it finds that they are different files. When you ask git checkout, it finds that they have the same content. This solution is temporarily instructing git to ignore any possible line-ending cleverness, and ensure that your local copy is byte-for-byte identical to that of HEAD. Once that has been resolved, allowing cleverness to resume is okay, because it won't add new errors. – Inodorous

Have spent a couple of hours dealing with this and this solution finally worked for me! – Agitator

Thx, as always reading whole topics reveals a working solution with minimal impact. It worked really fine on the couple of pesky files i had defying the normal undo changes in Visual Studio, leaving the rest as-is. – Trine

Worked for me this time! (Other answers here worked before, so each answer that works for me, will get a +1 :)) – Ezequieleziechiele

Answer 4

For future people having this problem: Having filemode changes can also have the same symptoms. git config core.filemode false will fix it.

Retake

After doing this, you may need to do a git checkout . – Retake

Worked for me without having to checkout again – Sardonic

For future reference: to know if this is the fix you need (and not the other fixes in other answers), use git diff and it will show files with mode changes like this old mode 100755 / new mode 100644. – Witching

This fixed it for me after absolutely nothing else would. I really don't think people should be making git cheatsheets and "simple guides" on the internet. Git really isn't something to just pick up and use, I think it's something you have to have dedicated and formal training and practice on before you use it. – Taphouse

Thanks, you saved me lots of tears! – Hatten

Answer 5

This has been driving me crazy, especially that I couldn`t fix this without any of the solutions found online. Here is how I solved it. Can't take the credits here since this is the work of a colleague :)

Source of the problem: My initial installation of git was without auto line conversion on windows. This caused my initial commit to GLFW to be without the proper line ending.

Note: This is only a local solution. The next guy cloning the repo will still be stuck with this problem. A permanent solution can be found here: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository.

Setup: Xubuntu 12.04 Git repo with glfw project

Problem: Unable to reset glfw files. They always show as modified, regardless of what I tried.

Solved:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Wakefield

It might be helpful to mention the contents of the commented line. – Corky

Unfortunately, most projects don't have this optional .gitattribute file – Corymb

Thank you. I just don't understand why this is necessary – Erasmoerasmus

Why? Basically, this is a temporary fix to the line ending. Use the permanent solution by following the link in the Note. – Wakefield

Answer 6

I had a .bat file with the same problem (couldn't get rid it it in untracked files). git checkout -- didn't work, neither did any of the suggestions on this page. The only thing that worked for me was to do:

git stash save --keep-index

And then to delete the stash:

git stash drop

Komsomol

This worked for me. Note that the --keep-index is important. – Equally

Why is the --keep-index important? – Dinsmore

Answer 7

Got the same issue twice! Both times when stash some changes I made and then tried to pop them back. Could'nt pop the changes since I've got lots of file that are changed -- but they are NOT! They are EXACTLY the same.

I now think I've tried all the above solutions without success. After trying the

git rm --cached -r .
git reset --hard

I now got almost all the files in my repository modified.

When diffing the file, it says I've deleted all the lines and then add them again.

Kind of disturbing. I will now avoid stashing in the future..

The only solution is to clone a new repository and start over. (Made it last time)

Nuptial

Answer 8

Try doing a

git checkout -f

That should clear all the changes in the current working local repo

Papageno

Nice! This worked for me. Although for one stubborn case I had to first git checkout -f <another recent branch> then go back to my branch with git checkout -f <branch I'm working on> – Ezequieleziechiele

Answer 9

Normally, in GIT to clear all your modifications & new files the following 2 commands should work very nicely (be CAREFUL, this will delete all your new files+folders you may have created & will restore all your modified files to the state of your current commit):

$ git clean --force -d
$ git checkout -- .

Maybe a better option sometimes is just doing "git stash push" with optional message, like so:

$ git stash push -m "not sure if i will need this later"

This will also clear all your new and modified files, but you'll have all of them stashed in case you want to restore them. Stash in GIT carries from branch to branch, so you can restore them in a different branch, if you wish to.

As a side note, in case you have already staged some newly added files and want to get rid of them, this should do the trick:

$ git reset --hard

If all of the above doesn't work for you, read below what worked for me a while ago:

I ran into this problem few times before. I'm currently developing on Windows 10 machine provided by my employer. Today, this particular git behavior was caused by me creating a new branch from my "develop" branch. For some reason, after I switched back to "develop" branch, some seemingly random files persisted and were showing up as "modified" in "git status".

Also, at that point I couldn't checkout another branch, so I was stuck on my "develop" branch.

This is what I did:

$ git log

I noticed that the new branch I created from "develop" earlier today was showing in the first "commit" message, being referenced at the end "HEAD -> develop, origin/develop, origin/HEAD, The-branch-i-created-earlier-today".

Since I didn't really need it, I deleted it:

$ git branch -d The-branch-i-created-earlier-today

The changed files were still showing up, so I did:

$ git stash

This solved my problem:

$ git status
On branch develop
Your branch is up to date with 'origin/develop'.

nothing to commit, working tree clean

Of course $ git stash list will show stashed changes, and since I had few and didn't need any of my stashes, I did $ git stash clear to DELETE ALL STASHES.

NOTE: I haven't tried doing what someone suggested here before me:

$ git rm --cached -r .
$ git reset --hard

This may have worked as well, I'll be sure to try it next time I run into this problem.

Outreach

Answer 10

I was only able to fix this by temporary deleting my repo's .gitattributes file (which defined * text=auto and *.c text).

I ran git status after deleting and the modifications were gone. They didn't return even after .gitattributes was put back in place.

Santamaria

This works even with more complicated gitattributes e.g. filters – Baler

Answer 11

The issue that I ran into is that windows doesn't care about filename capitalization, but git does. So git stored a lower and uppercase version of the file but could only checkout one.

Wartow

Answer 12

I had an older redundant branch with different line-endings. Switching to this got me a bit stuck until I applied some --force.

git checkout mainbranch --force

Followed by a swift git branch -D brokenbranch.

Fowler

This worked for me. Not sure how the end result differs from the other suggested answers though. It seems to me that it's always a good idea to make a backup of your entire local repo before doing anything involving --force or rm... – Valora

Answer 13

Having consistent line endings is a good thing. For example it will not trigger unnecessary merges, albeit trivial. I have seen Visual Studio create files with mixed line endings.

Also some programs like bash (on linux) do require that .sh files are LF terminated.

To make sure this happens you can use gitattributes. It works on repository level no matter what the value of autcrlf is.

For example you can have .gitattributes like this: * text=auto

You can also be more specific per file type/extension if it did matter in your case.

Then autocrlf can convert line endings for Windows programs locally.

On a mixed C#/C++/Java/Ruby/R, Windows/Linux project this is working well. No issues so far.

Fradin

Answer 14

I had also same symptoms but has been caused by different thing.

I was not able to:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

even on git rm --cached app.js it signs as deleted and in untracked files I could see app.js. But when I tried rm -rf app.js and peform git status again it still shows me the file in 'untracked'.

After couple of tries with colleague we found out, that it has been caused by Grunt!

As the Grunt has been turned on, and because app.js has been generated from couple of other js files we found out that after each operation with js files (also this app.js) grunt recreate app.js again.

Diamond

Answer 15

This issue can also occur when a contributor to the repo works on a Linux machine, or windows with Cygwin and file permissions are changed. Git only knows of 755 and 644.

Example of this issue and how to check for it:

git diff styleguide/filename

diff --git a/filename b/filename
old mode 100644
new mode 100755

To avoid this, you should make sure you setup git correctly using

git config --global core.filemode false

Teuton

Answer 16

There are a lot of solutions here and I maybe should have tried some of these before I came up with my own. Anyway here is one more ...

Our issue was that we had no enforcement for endlines and the repository had a mix of DOS / Unix. Worse still was that it was actually an open source repo in this position, and which we had forked. The decision was made by those with primary ownership of the OS repository to change all endlines to Unix and the commit was made that included a .gitattributes to enforce the line endings.

Unfortunately this seemed to cause problems much like described here where once a merge of code from before the DOS-2-Unix was done the files would forever be marked as changed and couldn't be reverted.

During my research for this I came across - https://help.github.com/articles/dealing-with-line-endings/ - If I face this problem again I would first start by trying this out.

---

Here is what I did:

1. I'd initially done a merge before realising I had this problem and had to abort that - git reset --hard HEAD (I ran into a merge conflict. How can I abort the merge?)

2. I opened the files in question in VIM and changed to Unix (:set ff=unix). A tool like dos2unix could be used instead of course

3. committed

4. merged the master in (the master has the DOS-2-Unix changes)

   git checkout old-code-branch; git merge master

5. Resolved conflicts and the files were DOS again so had to :set ff=unix when in VIM. (Note I have installed https://github.com/itchyny/lightline.vim which allowed me to see what the file format is on the VIM statusline)

6. committed. All sorted!

Wivinia

Answer 17

I commited all the changes and then did and undo on the commit. This worked for me

git add .

git commit -m "Random commit"

git reset --hard HEAD~1

Childe

Answer 18

If you clone a repository and instantly see pending changes, then the repository is in an inconsistent state. Please do NOT comment out * text=auto from the .gitattributes file. That was put there specifically because the owner of the repository wants all files stored consistently with LF line endings.

As stated by HankCa, following the instructions on https://help.github.com/articles/dealing-with-line-endings/ is the way to go to fix the problem. Easy button:

git clone git@host:repo-name
git checkout -b normalize-line-endings
git add .
git commit -m "Normalize line endings"
git push
git push -u origin normalize-line-endings

Then merge (or pull request) the branch to the owner of the repo.

Hairtail

Answer 19

Nothing else on this page worked. This finally worked for me. Showing no untracked, or commited files.

git add -A
git reset --hard

Cespitose

Answer 20

For me the problem was that Visual Studio was opened when performing the command

git checkout <file>

After closing Visual Studio the command worked and I could finally apply my work from the stack. So check all applications that could make changes to your code, for example SourceTree, SmartGit, NotePad, NotePad++ and other editors.

Belted

Answer 21

We faced a similar situation in our company. None of the proposed methods did not help us. As a result of the research, the problem was revealed. The thing was that in Git there were two files, the names of which differed only in the register of symbols. Unix-systems saw them as two different files, but Windows was going crazy. To solve the problem, we deleted one of the files on the server. After that, at the local repositories on Windows helped the next few commands (in different sequences):

git reset --hard
git pull origin
git merge

Legal

Answer 22

I solved it by editing .git / config, adding:

[branch "name_branch"]
    remote = origin
    merge = refs/heads/name_branch

Then I went to .git / refs / heads / name_branch and place the id of the last commitenter code here

Cataclysm

Answer 23

I solved it this way:

1. Copy the contents of the correct code you want
2. Delete the file that is causing the problem ( the one that you can't revert ) from your disk. now you should find both versions of the same file marked as being deleted.
3. Commit the deletion of the files.
4. Create the file again with the same name and paste in the correct code you have copied in step 1
5. commit the creation of the new file.

---

That's what worked for me.

Primine

Answer 24

One proposed solution here didn't work, I found out the file was actually a link to some special characters:

% ls -l StoreLogo.png
lrwxrwxrwx 1 janus janus 8 Feb 21 10:37 StoreLogo.png -> ''$'\211''PNG'$'\r\n\032\n'

% git status    
Changes not staged for commit:
    modified:   StoreLogo.png

% git rm --cached -r StoreLogo.png
rm 'src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png'

% git reset StoreLogo.png         
Unstaged changes after reset:
M   src/GWallet.Frontend.XF.UWP/Assets/StoreLogo.png

% git status                      
Changes not staged for commit:
    modified:   StoreLogo.png

Clearstory

Answer 25

.gitattributes with

test_file_with_crlf text eol=crlf 

doesn't mesh well with the file being actually CRLF in the repo (probably checked in with core.autocrlf=false)

Solution:

1. Re-add the file with autorcrlf=input (see git add --renormalize)
2. Try not to work on anything before this commit.

Tasimeter