1

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

dragonmnl
  • 14,578
  • 33
  • 84
  • 129
  • A bit confused @dragonmnl : Here you say autocrlf is not false. In comments below vonc answer you say it is. – Rusi Aug 02 '21 at 16:36

1 Answers1

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • --renormalize seems to make things worse (I updated my question) – dragonmnl Jun 14 '20 at 01:10
  • @dragonmnl worse? Or actually like you want them (with lf at the end)? – VonC Jun 14 '20 at 01:11
  • the remote repo was created on unix systems so all files should have LF endings. The issue I am having is that files appear changed (in spite of .gitattributes) and so they must be included in a commit to be marked as changed It's the warning git gives <> – dragonmnl Jun 14 '20 at 01:13
  • @dragonmnl Do you have `core.autocrlf` set to `false`? (https://stackoverflow.com/a/9094476/6309) – VonC Jun 14 '20 at 01:15
  • I do. I checked with `git config --list` – dragonmnl Jun 14 '20 at 01:20
  • @dragonmnl What version of Git are you using? (https://stackoverflow.com/a/44224929/6309) – VonC Jun 14 '20 at 01:22
  • git version 2.27.0.windows.1 – dragonmnl Jun 14 '20 at 01:23
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/215916/discussion-between-vonc-and-dragonmnl). – VonC Jun 14 '20 at 01:24