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.

Favourite

If you have core.filemode unset, or set to true, is the output different? – Gratification

The other important bit of information that would help is the output of git --version – Gratification

@AronRotteveel: That is easy: the first file has CRLF line-ends (windows), the second LF (Unix) – Cerebrospinal

git 2.8 (March 2016) introduces git ls-files --eol, to quickly see if eol is involved. See my answer below – Epicarp

The person on windows can run git config --global core.autocrlf true to solve this issue. – Uppermost

@Uppermost autocrlf=true can prevent this problem if used from the beginning, but would it actually fix the issue after the CRLFs are already in there? https://mcmap.net/q/11223/-why-should-i-use-core-autocrlf-true-in-git suggests it wouldn't. – Bogeyman

@KalindaPride, I think this issue with Git was been patched by Johannes Schindelin. Most of the mentions of this problem are several years old. – Uppermost

@Uppermost This past month I cloned a repo onto a new computer (newest version of git) and encountered this problem, with every file showing as modified due to line endings. If the issue has been patched as you say, maybe the problem was caused by previous committers because they were running older versions of git? Or did you mean that I could have updated git on the old (Windows) computer and then run "git config --global core.autocrlf true" there, and then the problem would be fixed? – Bogeyman

@KalindaPride you still need to deal with the underlying problem of how you want to deal with Line Endings on different systems. You might need a global gitattributes file or separate policies for *nix and windows. This answer might help https://mcmap.net/q/11253/-what-39-s-the-strategy-for-handling-crlf-carriage-return-line-feed-with-git, otherwise it would be better to post a Question with more details on your situation. – Uppermost

I got rid of the issue using: git add --renormalize . For details see configuring-git-to-handle-line-endings – Jacquard

error: unknown option `renormalize' – Honghonied

Answer 1

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

Cerebrospinal

The strange thing is that the md5sums for both files are different but I cannot find ANY whitespace difference. (I assume this is the case, but I simple do not see it). Any help would be welcome. – Favourite

Just upload an example somewhere (gist.github.com would be appropriate for this). I assume it is with newline on the last line, a byte-order-mark, or non-canonical UTF8 encodings in general. You can always look at xxd or bdiff to do binary diffs too – Cerebrospinal

thanks for the tip. xdd was new to me. Great tool! I updated my post with an example. – Favourite

@AronRotteveel: That is easy: the first file has CRLF line-ends (windows), the second LF (Unix). Edit The file util will show you that (file a b will reply something like a: ASCII text, with CRLF line terminators b: ASCII text) – Cerebrospinal

shouldn't those actually show as ^M in VIM? (I don't see it). Obviously, I believe you, but I'm really interested in how you actually noticed this :) – Favourite

@AronRotteveel: no, Vim detects the lineend style (do :se fileformat to see the value: unix or dos). Use that to convert as well: :se ff=unix | w. For completeness, vim shows the ugly ducklings (^M) iff you have mixed line-endings, in which case it chooses unix and the redundant ^M show up – Cerebrospinal

I'm my case the hash is the same, but git still indicates a change – Embroil

@Embroil Did the modes change (permissions?) – Cerebrospinal

git diff filename wasn't printing anything and they had the same md5 checksums. I just reverted the change 🤷‍♂️. – Baldpate

Answer 2

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/

Blighter

In my case I had made a bunch of notes to some files, then copied the repo without the .git folder to a new computer. When I realized I was missing my .git package, it was too late to go back and retrieve it. So I: 1. Checked out a new copy of the whole repo 2. Replaced the vanilla files with the files with my changes 3. Ran step one in the OP's post: git rm --cached -r . 4. This staged my changes (and any other files that got replaced) so I unstaged them. At this point my repo was back to normal. – Nook

Gotta be careful as you will lose any other changes if you do. – Adventist

I had this problem after copy&pasting my repo folder from Windows to Ubuntu. There were no local changes, but for some reason, git thought every single file has changed. This solution resolved this problem. – Humfrey

An excellent solution for those using Windows, but moving their development environment into Linux, or WSL (which is how I landed here). – Wershba

I kinda wish this was the official answer as it's a more general solution. CRLF is not the only cause of this. In my case I've gotten it several times from copying an entire repository (Linux --> Linux), and this was the only workable solution for me. – Bittencourt

This is the solution for those migrating a git project from Linux/Mac to Windows – Faus

The first command for me just wanted to delete a huge load of legitimate files. Had to revert and find another way – Tiga

I think git stash followed by git stash pop is a non-destructive way to fix this issue. Worked for me in a directory that I had rsync'd between machines. – Feuchtwanger

Note: You can also do git reset without using --hard so as to not lose any changes. – Citarella

This completely screwed up my solution, so thanks for that... – Bushwa

Answer 3

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

Hanzelin

Using Windows 10 lxss (i.e. Ubuntu Bash) with a repo in Windows filesystem with git in Linux, I had thought it was a line ending issue. Hadn't even considered it could have been the way file modes are different as well. – Lucy

This worked for me when I changed my local O/S from Ubuntu to Windows. Cheers – Legit

@MattL and itsandy I usually develop on Win 10 with Git Bash, but today I'm on Mac and see that git thinks .gitignore files have changed when they haven't. On this Mac, git config core.filemode responds with true. I changed it to false, but that didn't help. – Ladysmith

Why core.filemode is enabled by default? This probably ruined many clean repository histories. – Hagler

I did git config --system core.filemode false to override this setting system-wide. I don't care, it has to be false when not specified otherwise. – Hagler

I could find the diff by git diff but vs code did not show the difference. Here is an issue for this: github.com/microsoft/vscode/issues/15968, and a question: #40779722. Solution: Add "diffEditor.ignoreTrimWhitespace":false to settings.json – Rejuvenate

This is the solution typically when you're working on shared repositories and multiple OS's are commiting to the repo. – Astrakhan

In my case, those files are copied from NTFS to APFS, and file modes are changed but not content. This works perfectly. – Medford

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.

Ileana

Thanks, this was what I needed. I used @sehe's suggestion of comparing md5sum's to verify the files were identical (in my case they were). After that using the -u flag correctly filtered those files with no actual differences from those with changes. – Frizzell

Thanks, it was helpful. I had this problem after doing npm i in the root of my project. Somehow, many files were getting a different line endings, which was creating this issue. – Williamsen

this is what i expected...the changes which have done remains and rest got undo – Conlan

I struggled in the same situation. I used find . -print0 | xargs -0 dos2unix -ic0 | xargs -0 dos2unix -b to update line breaks from Windows to Linux and git add . to fix status. After it git status showed me all up to date status. It looks like a bug in the git, it shouldn't be necessary to execute git add . to fix git status. – Genuflection

Thanks, I just used git add -uv and it worked instantly. – Crush

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

Bedevil

Your answer saved me a lot of time. Thanks! – Jamie

After doing this, I recommend stashing/staging the desired changes, resetting/checking out the files that have had their permissions changed, and then re-enabling core.filemode. :) – Aspergillosis

I had this problem after copying the files from one laptop to another. Your fixed saved it. Thanks! – Intelligence

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://mcmap.net/q/11253/-what-39-s-the-strategy-for-handling-crlf-carriage-return-line-feed-with-git

Stern

Worked for me. We have a mixed environment with some Macs and some PCs. – Stubbs

Thanks, this helped me after switching from Win to Linux – Geaghan

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.

Epicarp

Although this shows the problem, it does not fix it. – Corkscrew

This provided the best clue in my situation. I had one gradlew.bat file that was modified, and no matter what I did to reset the working directory (git reset --hard && git status and git reset --hard && rm gradlew.bat && git status && git checkout . && git status) the file remained modified. I have a global .gitattributes from here: github.com/alexkaratarakis/gitattributes/blob/master/… with a few extra bits from here: rehansaeed.com/gitattributes-best-practices – Quadripartite

git ls-files --eol showed my gradlew.bat was one of/the only file that did not have text=auto set. In my ~/.gitattributes_global I had *.bat text eol=crlf so I tried text eol=lf but that didn't work. So then I tried text=auto in the .gitattributes_global and it fixed the issue. – Quadripartite

@DevinGRhode Well done! ls-files --eol is handy indeed. – Epicarp

I solved this again by adding a .gitattributes file to a repo with just * text=auto inside of it :) - maybe put this in around the top of your answer? – Quadripartite

@DevinGRhode Thank you. I have included your comment in the answer for more visibility. – Epicarp

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.

Harrington

This worked for me in a scenario where I'm using Visual Studio on Windows, but I am doing commits and additional checks in WSL on the command line. On command line, every file showed as changed, but in Visual Studio, only a few files changed. I added autoclrf = input in my .gitconfig file and it fixed it instantly. Thank you! – Woodbridge

Thanks. I had also moved from windows to linux. Your solution worked for me. – Oncoming

This is the solution if you are using VSCode with WSL on Windows! – Panthia

Answer 9

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

filemode = false

Jerrelljerri

This simple solution works for me. Thanks. – Screw

This answer explains why this works. The tldr is this is more of a workaround for an inconsistency in the file system. Consider addressing the inconsistency. – Allopath

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?

Gratification

git status simply shows an enormous list of files in the modified section. – Favourite

@Aron: based on that clue I'd say: 85% says lineend conversion – Cerebrospinal

Wow. A reminder of how unintelligible some of the official git docs are. – Disburse

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.

Goings

Only this works. In my case, I had to use --hard option. git reset HEAD^1 --hard – Schaper

Unfortunately, I had the issue again. I solved by these commands as described here, github.com/git-lfs/git-lfs/issues/1939#issuecomment-279841780 git lfs uninstall git reset --hard git lfs install && git lfs pull – Schaper

Answer 12

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

Fostoria

Answer 13

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

Windowsill

Answer 14

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.

Edition

Answer 15

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.

Lechery

Good catch. +1. That is why I always set my PATH myself, as in https://mcmap.net/q/11743/-error-when-trying-to-extract-hyperledger-artifacts – Epicarp

I often will let an installer set the PATH but then check it manually, which I did here. My previous install had git 2.4.x (x86) and I installed git 2.13.x (x64). You can imagine my confusion when I removed the x86 path reference and still got 2.4!! That's when I saw cygwin's bin directory and that seemed the next logical place to look. So FWIW setting or even checking your PATH visually might not solve this if the Cygwin bin directory is listed first! – Lechery

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.

Gratification

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.

Kloof

Welcome to Stack Overflow. This is a nine year old question with an accepted answer and a lot of existing answers. When adding another answer it is important to point out what new aspect of the question your answer addresses. It appears that your answer is answering a different git issue than the one in the question (file name case versus line endings). – Thermometer

Answer 18

i fixed with: git stash && git stash pop

Misplay

Answer 19

Try changing the Git configuration so that permission changes are ignored. Play in Terminal:

First run:

git status --porcelain=2 

Then

For the current repository

git config core.filemode false

Globally

git config --global core.filemode false

Boehmenism

Answer 20

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.

Campbell

Answer 21

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.

Molini

Answer 22

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.

Dolley

Answer 23

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

Ludwigg

Answer 24

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.

Wenda

Answer 25

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.

Custommade

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

Dialectology