Why does git think each line of an untouched file has changed

Question

I don't think it's a line ending difference issue - p4merge does not think anything has changed in the file, even when set to recognize line ending and white space differences.

My issue is that sometimes the following happens:

• At first git status shows no uncommitted changes.
• Then I checkout another branch
• Now git status lists some files as changed.
• git diff on any of those "changed files" shows every line of the file as changed. The changed version appears the same as the original version.

Why is this happening? Why does git think the files have changed, when they appear to not have done that? Why does just checking out another branch cause this?

My first thought was line endings, but I don't know why p4merge would not detect those. Second idea was file mode changes. I don't know how to find out if that's the case. git config --list shows core.filemode is set to false. git config --global --list and git config --system --list don't show any setting for core.filemode (I tell this here since I'm not sure how different config levels override each other). core.autocrlf is set to true.

Multiple developers commit to the same repository I'm pulling changes from, all on Windows machines. I'm guessing someone somewhere has some setting in a position that's causing this, but I don't know if it's me locally or someone else, or what setting it could be.

The files listed as changed don't appear to be random - if I delete my local repository, clone it again from the remote (which defaults to master branch being checked out), and checkout that same branch again, git status lists the exact same files as changed, every time. The files are sometimes something recently edited, sometimes files that have not been touched in years. They are also not only binary files (that core.autocrlf=true is known to corrupt at times), but text files as well.

Doing commands git rm --cached -r . followed with git reset --hard gets rid of the changes, but it's occurring so often it's getting bothersome. I'm also curious what could be causing this.

Same repository is also causing line ending problems. I think this is a separate issue, so I'll probably end up making another question for it, but I mention it here briefly in case it's related after all. Checking out another branch or pulling changes from remote repository sometimes causes files appear as changed, and git diff on those files only outputs warning: LF will be replaced by CRLF in [file]. The file will have its original line endings in your working directory.

Edit: The .gitattributes file of the repository has only the line * text=auto and nothing else in it.

Output of git config --list (ommitted settings with things like colors, file paths to editor, remote, difftool, user name and email and such):

core.symlinks=false
core.autocrlf=true3
pack.packsizelimit=2g
rebase.autosquash=true
merge.summary=true
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false (yes this is there twice, just noticed)
core.ignorecase=true
core.hidedotfiles=dotgitOnly

Answer 1

To show such "invisible" changes in details use:

git diff --word-diff-regex=.

This will mark all changed characters, even whitespace.

Most probably it will show a change in line endings. If you are working on Windows and turned on core.autocrlf, git might expect the other kind of line ending and show the "wrong" line ending as diff.

Telling git to not care about line endings by turning off core.autocrlf should fix your issue.