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  lt file gt      to update what will be committed       use  git checkout --  lt file gt      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  lt file gt      to update what will be committed       use  git checkout --  lt file gt      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  lt file gt      to update what will be committed       use  git checkout --  lt file gt      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  lt file gt      to update what will be committed       use  git checkout --  lt file gt      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

User · Answer

Nothing else on this page worked  This finally worked for me  Showing no untracked  or commited files    git add -A git reset --hard

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Normally  in GIT to clear all your modifications  amp  new files the following 2 commands should work very nicely  be CAREFUL  this will delete all your new files folders you may have created  amp  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

User · Answer

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

User · Answer

There are multiple problems the 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  gitattribute 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

User · Answer

Try doing a      git checkout -f    That should clear all the changes in the current working local repo

User · Answer

For me the problem was that Visual Studio was opened when performing the command   git checkout  lt file gt   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

User · Answer

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 - gt       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

User · Answer

I solved it this way    Copy the contents of the correct code you want 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  Commit the deletion of the files  Create the file again with the same name and paste in the correct code you have copied in step 1 commit the creation of the new file      That s what worked for me

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Another solution that may work for people  since none of the text options worked for me    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  Check that message for the offending files is gone  if it s not you can git checkout --  lt files gt  to restore them to the repository version git checkout --  gitattributes to restore the  gitattributes file to its initial state Check that the files are still not marked as changed

User · Answer

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

User · Answer

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    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   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 committed merged the master in  the master has the DOS-2-Unix changes   git checkout old-code-branch   git merge master 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  committed   All sorted

User · Answer

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

User · Answer

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

User · Answer

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

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

Examples related to git

Examples related to revert

Examples related to git-status

Examples related to working-copy