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=<removed>
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=<removed>
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 definitely 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--..<p
0000050: 3e0d 0a20 2020 2057 6865 7468 6572 206f  >..    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...</p>..--
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--.<p>.   
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..</p
00001a0: 3e0a 2d2d 2320 7669 6d3a 2065 7420 7377  >.--# vim: et sw
00001b0: 3d34 2073 7473 3d34 0a                   =4 sts=4.

Answer 1

I have resolved this problem using following steps

1. Remove every file from Git's index.

   git rm --cached -r .

2. 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/

Answer 2

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

Answer 3

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

Answer 4

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. After that git status shows only 3 modified files. After git commit everything is ok with git status.

Answer 5

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

Answer 6

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

Answer 7

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 be 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 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 ("eolinfo") are shown like this:

"-text"        binary (or with bare CR) file
"none"         text file without any EOL
"lf"           text file with LF
"crlf"         text file with CRLF
"mixed"        text file with mixed line endings.

The effective text/eol attribute is one of these:

"", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf"

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'), in the working tree ('w'), and what attribute is in effect, for each path that is shown.

Answer 8

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.

Answer 9

I just set filemode = false into [core] section in .git/config file and it worked for me.

filemode = false

Answer 10

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?

Answer 11

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 "temporary" 

# this doesn't change contents
git reset HEAD^1 --soft    

After that, git status showed only one editted file that I editted.

Answer 12

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

Answer 13

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.

Answer 14

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.

Answer 15

Files show as modified when running git-status. However git-diff says they are the same (not a real quote, but a summary of the problem)

TLDR use

git add --renormalize <file-name>

There are 3 cases where I have observed this problem

1. file-mode/permissions are different between working tree and index
2. EOL issues for text files, especially when working with CRLF endings in a *nix environment
3. file attributes differ between when the file was committed and when running git-status

(1) File mode discrepancies happen when switching between Windows and Unix/cygwin environments. Best is to ignore the file mode globally on your machine for all repos. Just run

git config --global core.filemode false

to add this setting to your global .gitconfig which is located in your home folder. Without --global you can add it to the current repository config file. This will fix the problem going forward, but for files that have been committed you need to go to (3)

(2) EOL differences was what brought me here. If you have fixed the line ending problem and committed, but are still running into the problem where status says "modified", you'll need to first set proper attributes by file type in .gitattributes in the root folder of your repository, .e.g add

*.bat    text eol=crlf
*.vcproj text eol=crlf
*.sh     text eol=lf

You will notice that the problem persists. That's because the cache is out of date. Running

git diff <file-name> shows no difference, while git diff --cache <file-name> will show the difference in the EOL

To fix look at #3

(3) Renormalize - Changes to the global settings or .gitattributes are not applied automatically for already committed files. To update the file attributes you need to run

git add --renormalize <file-name>

On the files that still appear as modified

Answer 16

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.

Answer 17

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.

Answer 18

i fixed with: git stash && git stash pop

Answer 19

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.

Answer 20

In my case, git was cloning slow, so I just copied the cloned repo from my Mac to Windows and none of these helped. What did help is doing a clone of the copied repo and used that instead and that seems to have fixed it. I am assuming there are some options set by default that differ cross platform that could cause the issue.

Answer 21

If file modes or line endings or white spaces are same, maybe it's just git index that keeps them modified. In this case simple command helps:

git reset

For me, the IDE was adding files automatically to the index, so when I removed them and then put the same files back, surprisingly they were shown as modified.

Answer 22

Did you run a formatter? Check the quotes.

For me, this phenomenon occurred after I ran a formatter. Upon comparing I could see no changes as the starting and ending visible length were the same and characters took the same amount of size.

Finally, after some time, I realized that single quotes had been updated to double quotes and I kept missing them because the both types of quotes took up the same character space!

i.e. here is an example git change

-here is a contrived line for 'illustration' purposes
+here is a contrived line for "illustration" purposes

Answer 23

I got here because git diff file.abc would show, that the file were completely removed. But on the drive they had not changed.

Problem was: I am using git filters for cleanup and one of the commands was giving an error, that was not shown by git diff file.abc. The warning message only showed up during git reset file.abc.

If git diff shows your file contents vanish, try disabling the filters in your .gitattribute.

Answer 24

Finally I could find answer:

We have two type for line ending that will cause git diff, but git diff is not showing anything

$ecsConfig->lineEnding("\n"); // or \r\n

You can search more about \n LF and \r\n CRLF that is created by code-style checker or by your editor,

I was using easy-code-standards package and it was using PHP_EOL that is CRLF generaly, so vscode EOL is LF and that was creating disaster for me.

Answer 25

Try changing the Git configuration so that permission changes are ignored:

For the current repository

git config core.filemode false

Globally

git config --global core.filemode false

Answer 26

Try with a script that simply removes the problematic files, having previously made a backup of such files, and then throws them into the repository. This works because files are newly committed using the line termination format of the system.

This works standing at the root of the repository

mkdir ../backup_clean_git_file
git status --porcelain | awk 'match($1, "M") {print $2}' | while read -r file; do
    mkdir -p "../backup_clean_git_file/$(dirname "$file")"
    cp -f "$file" "../backup_clean_git_file/$file"
done
git status --porcelain | awk 'match($1, "M"){print $2}' | xargs git rm -f
git add .
git commit -m "backup taking out corrupted files"
cp -r ../backup_clean_git_file/* .
git add .
git commit -m "restoring corrupted files"
rm -rf ../backup_clean_git_file