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:
git status
shows no uncommitted changes.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
These changes mean that metadata about your file changed, however the content of your file did not. If you're working in a group, this may start to intefere with pushes or just add noise to your commits.
Indexing. For every tracked file, Git records information such as its size, creation time and last modification time in a file known as the index. To determine whether a file has changed, Git compares its current stats with those cached in the index. If they match, then Git can skip reading the file again.
However, it does not modify line endings in your working tree. This is essentially the same as setting core. autocrlf=input in your Git settings. More specifically, the text=auto option tells Git to only normalize line endings to LF for text files while leaving binary files (images, fonts, etc.)
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With