Git pull on Windows (git smc client) doesn't respect .gitattributes's eol=lf

Question

I am working on a project originally developed in Unix environment.

Such project has a .gitattributes file with forcing eol=lf over standard crlf-lf conversion

*.sh text eol=lf

which is my understanding is telling git "keep the original LF line endings".

When I clone this repository, in the moment the pull is complete, If I do git status, some files are marked as changed already (specifically .sh files)

git diff shows

-FileContent
+FileContent

where FileContent is all the text in the file.

I tried to:

• git reset --hard
• git update-index --assume-unchanged
• git config --global core.autocrlf false
• git config --global core.eol lf
• dos2unix on single files
• changing line endings for specifi files to \n with my editor (Phpstorm)

None had effect on the issue.

I also tried:

• git rm --cached -rf . -> this deleted a lot of files in the project
• to re-fetch a specific branch ( `git fetch; git checkout HEAD path/)
• git add --renormalize . -> all the .sh files appear as modified (it was only 1 after refetching the file from the branch following the above configuration)
• git diff --ignore-all-space shows nothing
• od path/file.sh shows a binary version of the file (before setting the above configuration was actually text)

How can I make git respect the eol=of value for .sh files?

---

Edit: after removing the index via rm .git/index and performing git reset --hard HEAD, the problem was gone

Also (for reference): didn't try - core.autocrlf to false

Answer 1

Regarding eol conversion:

1. Make sure core.autocrlf is set to false (that way, only [.gitattributes directives]1 will be in play)
2. Use text eol=lf
3. Follows by git add --renormalize . to force the application of the .gitattributes directives. (since Git 2.16, Q1 2018)

after removing the index via rm .git/index and performing git reset --hard HEAD, the problem was gone

That is what git add --renormalize . is supposed to emulate.