git status shows modifications even with autocrlf=false

Asked 12/6, 2012 at 22:18 Answered 13/1, 2014 at 8:36

Solved git revert git-status core.autocrlf

I'm experiencing the same issues as in this question: git status shows modifications, git checkout -- <file> doesn't remove them

Git continues to show working directory modifications, even with git config --global core.autocrlf false:

E:\_dev\github\Core [master +0 ~93 -0]> git config --get-all core.autocrlf
false
false

(Note that I've even set the --system setting to be false)

Why does it appear that Git is still modifying my end of lines?

Attempts to get rid of modifications

Baseline

E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

git checkout -- .

E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed) 
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
... more changes ...
no changes added to commit (use "git add" and/or "git commit -a")

Occasionally this will have an effect in an odd way:

E:\_dev\github\Core [master +0 ~628 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~361 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .
E:\_dev\github\Core [master +0 ~93 -0]> git checkout -- .

git reset --hard

E:\_dev\github\Core [master +0 ~93 -0]> git reset --hard
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master
E:\_dev\github\Core [master +0 ~93 -0]>

git add .; git stash; git stash drop

E:\_dev\github\Core [master +0 ~93 -0]> git add .
... warnings ....
warning: CRLF will be replaced by LF in tools/StatLight/StatLight.EULA.txt.
The file will have its original line endings in your working directory.

E:\_dev\github\Core [master +0 ~93 -0]> git stash
Saved working directory and index state WIP on master: 11a7f9a Merge pull request #8 from 
RemiBou/master
HEAD is now at 11a7f9a Merge pull request #8 from RemiBou/master

E:\_dev\github\Core [master +0 ~93 -0]> git stash drop
Dropped refs/stash@{0} (de4c3c863dbad789aeaf563b4826b3aa41bf11b7)

E:\_dev\github\Core [master +0 ~93 -0]> git status .\tools\StatLight\StatLight.EULA.txt
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   tools/StatLight/StatLight.EULA.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Indecent answered 12/6, 2012 at 22:18 Comment(2)

I have this problem here - they are likely the same problem. In my question I also verified no gitattributes are interfering. – Jd 28/3, 2013 at 15:42

@Jd could you put the output of git config -l in a pastebin and link it here? And make sure there is no .gitattributes in your project root or any other folder. – Boutis 30/3, 2013 at 3:1

This seems like a bug in msysgit indeed. As a workaround, try creating a .gitattributes file containing

* -text

This will tell git not to perform EOL conversions on any files.

Unwinking answered 1/3, 2013 at 15:39 Comment(3)

Seems the bug is not restricted to msysgit. Can reproduce it on Mac OS X easily: #22823504 – Stites 3/4, 2014 at 11:5

After looking at dozens of stackoverflow posts about git and line endings, this is the one that saved me! – Intervale 20/6, 2014 at 20:54

It did not help in my case, git still shows a file is modified even though I have "core.autocrlf false" and an attribute file with above content under .git/info – Brioche 11/11, 2022 at 23:46

Check if you have no .gitattributes file

As mentioned in the "Effect" section of the gitattributes man page, those files can also have an effect on eol and automatic transformation:

text ^^^^^^

This attribute enables and controls end-of-line normalization.
When a text file is normalized, its line endings are converted to LF in the repository.
To control what line ending style is used in the working directory, use the eol attribute for a single file and the core.eol configuration variable for all text files.

Check also your config for core.eol, as mentioned in "How line ending conversions work with git core.autocrlf between different operating systems".

Git 2.41 (Q2 2023) includes a doc update to clarify how text and eol attributes interact to specify the end-of-line conversion.

See commit 6696077 (02 May 2023) by Alex Henrie (alexhenrie).
^{(Merged by Junio C Hamano -- gitster -- in commit c05615e, 10 May 2023)}

docs: rewrite the documentation of the text and eol attributes

^{Helped-by: Torsten Bögershausen}
^{Signed-off-by: Alex Henrie}

These two sentences are confusing because the description of the text attribute sounds exactly the same as the description of the text=auto attribute:

"Setting the text attribute on a path enables end-of-line normalization"

"When text is set to "auto", the path is marked for automatic end-of-line conversion"

Unless the reader is already familiar with the two variants, there's a high probability that they will think that "end-of-line normalization" is the same thing as "automatic end-of-line conversion".

It's also not clear that the phrase "When the file has been committed with CRLF, no conversion is done" in the paragraph for text=auto does not apply equally to the bare text attribute which is described earlier.
Moreover, it falsely implies that normalization is only suppressed if the file has been committed.
In fact, running git add^(man) on a CRLF file, adding the text=auto attribute to the file, and running git add again does not do anything to the line endings either.

On top of that, in several places the documentation for the eol attribute sounds like either it does not affect normalization on checkin or it forces normalization on checkin.
It also sounds like setting eol (or setting a config variable) is required to turn on conversion on checkout, but the text attribute can turn on conversion on checkout by itself if eol is unspecified.

Rephrase the documentation of text, text=auto, eol, eol=crlf, and eol=lf to be clear about how they are the same, how they are different, and in what cases conversion is performed.