1

Have a problem with autocrlf option on win10 machine.

On win10 machine do:

$ git init
Initialized empty Git repository in ...

$ nano .git/config (add autocrlf=false line to core)

$ git config --list | grep crlf
core.autocrlf=false
core.autocrlf=false
core.autocrlf=false

$ git remote add origin ssh://...

$ git pull origin dev
remote: Enumerating objects: 1624, done.
remote: Counting objects: 100% (234/234), done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 1624 (delta 161), reused 152 (delta 113), pack-reused 1390
Receiving objects: 100% (1624/1624), 1.17 MiB | 939.00 KiB/s, done.
Resolving deltas: 100% (935/935), done.
From ssh://...
 * branch            dev        -> FETCH_HEAD
 * [new branch]      dev        -> origin/dev

$ xxd app/Http/Controllers/CatalogController.php | head -n 1
00000000: 3c3f 7068 700d 0a0d 0a6e 616d 6573 7061  <?php....namespa

I see CRLF (0d0a) symbols that doesn't exists in origin. Origin contains only LF (0a). To check this i'm reproduced this command sequence in Ubuntu:

$ git init
Initialized empty Git repository in 

$ nano .git/config (add autocrlf=false line to core)

$ git config --list | grep crlf
core.autocrlf=false

$ git remote add origin ssh://...

$ git pull origin dev
remote: Enumerating objects: 1624, done.
remote: Counting objects: 100% (234/234), done.
remote: Compressing objects: 100% (115/115), done.
remote: Total 1624 (delta 161), reused 152 (delta 113), pack-reused 1390
Receiving objects: 100% (1624/1624), 1.17 MiB | 74.88 MiB/s, done.
Resolving deltas: 100% (935/935), done.
From ssh://...
 * branch            dev        -> FETCH_HEAD
 * [new branch]      dev        -> origin/dev

$ xxd app/Http/Controllers/CatalogController.php | head -n 1
00000000: 3c3f 7068 700a 0a6e 616d 6573 7061 6365  <?php..namespace

On ubuntu everything is ok, i see LF (0a) that corresponds origin content. Also, i donwloaded zip archive from gitlab webui (gitlab self hosted). In this archive i see just LF (0a) in file app/Http/Controllers/CatalogController.php, as expected.

Looks like a problem just on win10 machine. Help please, whats wrong in my case?

UPD: thanks to @Anonymoose, additional info from git ls-files command on win10 machine:

$ git ls-files --eol | grep Catalog
i/lf    w/crlf  attr/text=auto          app/Http/Controllers/CatalogController.php

In index i have LF, but in working tree i have CRLF. From Git documentation (https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration):

Git can handle this by auto-converting CRLF line endings into LF when you add a file to the index, and vice versa when it checks out code onto your filesystem. You can turn on this functionality with the core.autocrlf setting. If you’re on a Windows machine, set it to true — this converts LF endings into CRLF when you check out code

As I uderstanding, autocrlf = false prevent replacing LF to CRLF during commits and checkouts. But in my case it dosn't.

Dennosaur
  • 65
  • 5

1 Answers1

1

Check first if your repository has a .gitattributes file with a directive like:

*     text=auto

# or
*.php text=auto

Try:

echo "*.php text eol=lf" >>.gitattributes
git add --renormalize .
git status        # Show php files that will be normalized
git commit -m "Introduce end-of-line normalization"

The OP Dennosaur confirms in the comments the .gitattributes file content was the issue, and uses:

*.php text=auto eol=lf
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I'm forgot to check .gitattributes file... Problems was here. I have text=auto that has more high priority than core.autocrlf. text=auto means use system dependent line ending. Solved with text=auto eol=lf in .gitattributes. Thank you! – Dennosaur Feb 27 '23 at 18:32
  • @Dennosaur Great, well done! I have included your comment in the answer for more visibility. – VonC Feb 27 '23 at 19:52