git status shows modifications even with autocrlf=

Question

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

Answer 1

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

Answer 2

Although i don't know what is causing this weird behaviour, i know one more way of discarding changes that might work.

Warning! Be extremely careful and do a backup first; this can be highly destructive.

If all data that you care about is committed in the repository, you can simply delete everything in your working directory (of course except hidden .git directory) and run git reset --hard HEAD to have git recreate the working directory solely from the repository data.

Remember to carefully check if you don't have any important data that is not tracked by git before doing this. It's not enough to check git status for uncommitted changes - remember that deleting all files from the working dir will also delete files which you told git to ignore, and they won't be recreated with git reset --hard HEAD because they're not tracked at all.

Answer 3

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.

Answer 4

I'm investigating the weird behavior of core.autocrlf in MSysGit, and I found that having:

[core]
    autocrlf = false
    safecrlf = true
    ignorecase = true
    eol = native 

in the global config file and NO core.autocrlf setting in a repo copied from another PC (not cloned, only copied), issuing a git status command results in ALL text files marked as modified (no gitattributes around).

But if you add a local (repository) core.autocrlf setting to true, and then issue a git status command, all the changes disappears and the repository turns back to be clean.

BUT (and this is the strange behavior) if you remove the just added core.autocrlf setting from the repository config file (thus returning to the exact initial state), the git status command continues to report no changes!

Given that no operations has been performed on the repository, only changing a config setting, and reverting back to the original state, has done the trick...

If this isn't a bug, I can't imagine who in the world can call this a "normal" behavior.

Answer 5

This problem can be caused by gitattributes' text option.

Please read the documentation carefully but essentially autocrlf only matters if text is not set in a .gitattributes:

Unspecified
If the text attribute is unspecified, git uses the core.autocrlf configuration variable to determine if the file should be converted.

Find your .gitattributes file via:

find <root-dir> -name .gitattributes

And grep for text, eol or crlf to find your culprit and revise as necessary.

You may just change this file and revert the change without committing for long enough to get through your issue.

Answer 6

"autocrlf" issue is a typical issue for cross multi platform repo (i.e. using a samba share with tortoisegit over a server under linux)

I realized, that sometimes (often), it's more a "chmod" issue than a autocrlf one : - git status windows display pending modifications - git status linux display nothing

"mode change 100755 => 100644 config/packager.xml"

Check that your "static" files are not +x, (and in this case tortoisegit wont like it)