Git status shows files as changed even though contents are the same

Question

I received a git checkout from someone else and am trying to commit the unstaged changes to the local repository  However  a lot  if not every  file appears as modified even though the contents are exactly the same   I already set core fileMode to false and also set core autocrlf to false  without success   Worth mentioning is that the Git repo I received was from someone using Windows  while I use Linux   What can I do to commit the actual changes   EDIT  output of git config -l   user name Aron Rotteveel user email  lt removed gt  color diff auto color status auto color branch auto color interactive auto color ui true color pager true color branch current yellow reverse color branch local yellow color branch remote green color diff meta yellow bold color diff frag magenta bold color diff old red bold color diff new green bold color status added yellow color status changed green color status untracked cyan core pager less -FRSX core whitespace fix -indent-with-non-tab trailing-space cr-at-eol alias co checkout core repositoryformatversion 0 core filemode false core bare false core logallrefupdates true core symlinks false core ignorecase true core hidedotfiles dotGitOnly core autocrlf false remote origin url  lt removed gt  remote origin fetch  refs heads   refs remotes origin     Update  added some random example files  These files are just plaintext  so are the easiest to include   Original files are located here  https   gist github com c3c5302430935155ef3d  Hexdumps definately indicate that the files are different  but I have no clue what causes this  and how to fix it   HEAD version   0000000  4854 4d4c 2e53 6166 654f 626a 6563 740d  HTML SafeObject  0000010  0a54 5950 453a 2062 6f6f 6c0d 0a56 4552   TYPE  bool  VER 0000020  5349 4f4e 3a20 332e 312e 310d 0a44 4546  SION  3 1 1  DEF 0000030  4155 4c54 3a20 6661 6c73 650d 0a2d 2d44  AULT  false  --D 0000040  4553 4352 4950 5449 4f4e 2d2d 0d0a 3c70  ESCRIPTION--   lt p 0000050  3e0d 0a20 2020 2057 6865 7468 6572 206f   gt       Whether o 0000060  7220 6e6f 7420 746f 2070 6572 6d69 7420  r not to permit  0000070  6f62 6a65 6374 2074 6167 7320 696e 2064  object tags in d 0000080  6f63 756d 656e 7473 2c20 7769 7468 2061  ocuments  with a 0000090  206e 756d 6265 7220 6f66 2065 7874 7261   number of extra 00000a0  0d0a 2020 2020 7365 6375 7269 7479 2066        security f 00000b0  6561 7475 7265 7320 6164 6465 6420 746f  eatures added to 00000c0  2070 7265 7665 6e74 2073 6372 6970 7420   prevent script  00000d0  6578 6563 7574 696f 6e2e 2054 6869 7320  execution  This  00000e0  6973 2073 696d 696c 6172 2074 6f0d 0a20  is similar to    00000f0  2020 2077 6861 7420 7765 6273 6974 6573     what websites 0000100  206c 696b 6520 4d79 5370 6163 6520 646f   like MySpace do 0000110  2074 6f20 6f62 6a65 6374 2074 6167 732e   to object tags  0000120  2020 596f 7520 7368 6f75 6c64 2061 6c73    You should als 0000130  6f20 656e 6162 6c65 0d0a 2020 2020 254f  o enable       O 0000140  7574 7075 742e 466c 6173 6843 6f6d 7061  utput FlashCompa 0000150  7420 696e 206f 7264 6572 2074 6f20 6765  t in order to ge 0000160  6e65 7261 7465 2049 6e74 6572 6e65 7420  nerate Internet  0000170  4578 706c 6f72 6572 0d0a 2020 2020 636f  Explorer      co 0000180  6d70 6174 6962 696c 6974 7920 636f 6465  mpatibility code 0000190  2066 6f72 2079 6f75 7220 6f62 6a65 6374   for your object 00001a0  2074 6167 732e 0d0a 3c2f 703e 0d0a 2d2d   tags    lt  p gt   -- 00001b0  2320 7669 6d3a 2065 7420 7377 3d34 2073    vim  et sw 4 s 00001c0  7473 3d34 0d0a                           ts 4     Copied version   0000000  4854 4d4c 2e53 6166 654f 626a 6563 740a  HTML SafeObject  0000010  5459 5045 3a20 626f 6f6c 0a56 4552 5349  TYPE  bool VERSI 0000020  4f4e 3a20 332e 312e 310a 4445 4641 554c  ON  3 1 1 DEFAUL 0000030  543a 2066 616c 7365 0a2d 2d44 4553 4352  T  false --DESCR 0000040  4950 5449 4f4e 2d2d 0a3c 703e 0a20 2020  IPTION--  lt p gt      0000050  2057 6865 7468 6572 206f 7220 6e6f 7420   Whether or not  0000060  746f 2070 6572 6d69 7420 6f62 6a65 6374  to permit object 0000070  2074 6167 7320 696e 2064 6f63 756d 656e   tags in documen 0000080  7473 2c20 7769 7468 2061 206e 756d 6265  ts  with a numbe 0000090  7220 6f66 2065 7874 7261 0a20 2020 2073  r of extra     s 00000a0  6563 7572 6974 7920 6665 6174 7572 6573  ecurity features 00000b0  2061 6464 6564 2074 6f20 7072 6576 656e   added to preven 00000c0  7420 7363 7269 7074 2065 7865 6375 7469  t script executi 00000d0  6f6e 2e20 5468 6973 2069 7320 7369 6d69  on  This is simi 00000e0  6c61 7220 746f 0a20 2020 2077 6861 7420  lar to     what  00000f0  7765 6273 6974 6573 206c 696b 6520 4d79  websites like My 0000100  5370 6163 6520 646f 2074 6f20 6f62 6a65  Space do to obje 0000110  6374 2074 6167 732e 2020 596f 7520 7368  ct tags   You sh 0000120  6f75 6c64 2061 6c73 6f20 656e 6162 6c65  ould also enable 0000130  0a20 2020 2025 4f75 7470 7574 2e46 6c61        Output Fla 0000140  7368 436f 6d70 6174 2069 6e20 6f72 6465  shCompat in orde 0000150  7220 746f 2067 656e 6572 6174 6520 496e  r to generate In 0000160  7465 726e 6574 2045 7870 6c6f 7265 720a  ternet Explorer  0000170  2020 2020 636f 6d70 6174 6962 696c 6974      compatibilit 0000180  7920 636f 6465 2066 6f72 2079 6f75 7220  y code for your  0000190  6f62 6a65 6374 2074 6167 732e 0a3c 2f70  object tags   lt  p 00001a0  3e0a 2d2d 2320 7669 6d3a 2065 7420 7377   gt  --  vim  et sw 00001b0  3d34 2073 7473 3d34 0a                    4 sts 4

User · Answer

I recently moved my local repo from one Windows x64 system to another   The first time I use it half my files appear to be changed   Thanks to Jacek Szybisz for sending me to Configuring Git to handle line endings where I found the following one-liner that removed all the no-change files from Gitkraken s change queue  git config --global core autocrlf true

User · Answer

For me it was because 2 linux VMs were both mapped to the same home file system  One VM was running git-1 7 1 an the other was running git-2 14  The VM running git-1 7 1 would always show 4 files as changed  even thought the contents and line endings were identical    Once  git status  was run on the VM running g-2 14  then both VMs would start reporting the repository as clean   git status  has side effects  It is not an immutable operation  And git-1 7 1 does not understand the world in the same way that git-2  does

User · Answer

i had the same problem  after win- lin copy i ve got all files modified  i used fromdos to fix line endings and then  git add -uv    to add changes  it added 3 files  not all of them   which i actually modified  and after that git status shows only 3 modified files  after git commit everything is ok with git status

User · Answer

Update  as per the comment on this question  the problem has been solved      That is easy  the first file has CRLF line-ends  windows   the second   LF  Unix   The file util  available in git usr bin  will show you that  file a b will reply   something like a  ASCII text  with CRLF line terminators b  ASCII   text    Original answer below     The diff you show does not show a single different line  Can you post  git config  or better git config -l     You might have some whitespace ignores activated  You should try to disable core whitespace fix -indent-with-non-tab trailing-space cr-at-eol    also   git show HEAD myfile md5sum md5sum myfile   could be used to verify that the files are in fact different  Using external diff could work as well  git show HEAD myfile  gt   tmp myfile HEAD  diff -u myfile  tmp myfile HEAD    or if you prefer an interactive tool like e g   vim -d myfile  tmp myfile HEAD

User · Answer

In my case  files were exactly the same  content  line endings  filemodes  md5 checksum  everything   yet were still visible in git status  What helped was   Garbage collect stuffs from  git git gc    commit stuff git add    git commit -m  quot temporary quot      this doesn t change contents git reset HEAD 1 --soft      After that  git status showed only one editted file that I editted

User · Answer

So  I tried just about everything here and want to contribute one more solution that fixed all of my problems  My issues was not with line endings or actual permissions or anything like that  It was because I had installed Cygwin and whole host of stuff that comes with that  which unbeknownst to me also installed its own version of git  I never noticed this  just that I was having strange issues with users and files being marked as changed  because of perms changes    It turns out that I figured this out because I thought I should just update Git to the latest version  which I did  but running git --version returned the old version number  After the ensuing hunt for why  I found the cygwin bin directory root in my environment path  which contained a git executable  running at the old version number  Go figure   This was also hard to find because I have TortoiseGit installed  My command line tools would use the cygwin version due to path fallbacks  and TortoiseGit was configured to use the windows version  making it even more confusing   Hope this helps somebody

User · Answer

The Git FAQ has an answer that might be relevant  although I ve never come across this before      Why does git diff sometimes list a file that has no changes       git diff and other git operations is optimized so it does not even look at files whose status  size  modification time etc  on disk and in git s index are different  This makes git diff extremely fast for small changes  If the file has been touched somehow  git diff has to look at the content of and compare it which is a much slower operation even when there is in fact no change  git diff lists the files as a reminder that it is not used optimally  Running git status will not only show status  but will also update the index with status for unchanged files disk making subsequent operations  not only diff  much faster  A typical case that causes many files to be listed by diff is running mass editing commands like perl -pi -e           What does git status show for you

User · Answer

For me the issue was a case difference in the file  I renamed the file and committed the delete  It showed both the upper and lower case versions of the file to be deleted  After the delete was committed I renamed the file back to its original name and pushed

User · Answer

In my case the files were appeared as modified after changing the files permissions    To make git ignore permission changes  do the following      For the current repository git config core filemode false       Globally git config --global core filemode false

User · Answer

Have you changed the mode of the files  I did it on my machine and the local dev machine had 777 given to all the files whereas the repo had 755 which showed every file as modified  I did git diff and it showed the old mode and new mode are different  If that is the problem then you can easily ignore them by  git config core filemode false Cheers

User · Answer

I was able to fix the problems on Windows machine by changing core autocrlf from false to  core autocrlf input  git config core autocrlf input   as it s suggested in https   stackoverflow com a 1112313 52277

User · Answer

However  a lot  if not every  file appears as modified even though the contents are exactly the same   With git 2 8  March 2016   you will able to quickly check if those changes are eol-related  If that is the case  Devin G Rhode adds in the comments   I solved this again by adding a  gitattributes file to a repo with just   text auto inside of it  For the check  see commit a7630bd  16 Jan 2016  by Torsten B  gershausen  tboegi    Merged by Junio C Hamano -- gitster -- in commit 05f1539  03 Feb 2016   ls-files  add eol diagnostics   When working in a cross-platform environment  a user may want to check if text files are stored normalized in the repository and if  gitattributes are set appropriately    Make it possible to let Git show the line endings in the index and in the working tree and the effective text eol attributes    The end of line   quot eolinfo quot   are shown like this    quot -text quot         binary  or with bare CR  file  quot none quot          text file without any EOL  quot lf quot            text file with LF  quot crlf quot          text file with CRLF  quot mixed quot         text file with mixed line endings    The effective text eol attribute is one of these    quot  quot    quot -text quot    quot text quot    quot text auto quot    quot text eol lf quot    quot text eol crlf quot    git ls-files --eol gives an output like this   i none   w none   attr text auto      t t5100 empty i -text  w -text  attr -text          t test-binary-2 png i lf     w lf     attr text eol lf    t t5100 rfc2047-info-0007 i lf     w crlf   attr text eol crlf  doit bat i mixed  w mixed  attr                locale XX po   to show what eol convention is used in the data in the index   i    and in the working tree   w    and what attribute is in effect  for each path that is shown

User · Answer

I just set filemode   false in  git config and it worked for me   filemode   false

User · Answer

Here is how I fixed the problem on Linux while I cloned a project that was created on Windows   on linux in order for things to work properly you have to have this setting  core autocrlf input  this is how to set it  git config --global core autocrlf input  Then clone the project again from github

User · Answer

After copying my local repository and working copy to another folder  on Windows by the way   I had four files that kept showing up as changed and tried every suggestion listed in the other answers  In the end what fixed it for me was deleting the local branch and downloading it again from the remote  In my case I guess it had something to do with copying a local repository rather than cloning

User · Answer

I have resolved this problem using following steps  Remove every file from Git s index  git rm --cached -r    Rewrite the Git index to pick up all the new line endings  git reset --hard   Note that step 2 may remove your local changes  Solution was part of steps described on git site https   help github com articles dealing-with-line-endings

User · Answer

The only suspect entry in your config looks to me to be core ignorecase   You could try unsetting that with     git config --unset core ignorecase       and see if the output from git status or git diff is different

[git] Git status shows files as changed even though contents are the same

Examples related to git