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

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

Solution

Regarding eol conversion:

Make sure core.autocrlf is set to false (that way, only [.gitattributes directives]1 will be in play)
Use text eol=lf
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.