skip to Main Content

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.

2

Answers


  1. It’s possible that some of the files in your local repository still have incorrect line endings due to previous commits with the wrong settings. To fix this, you can use the git reset and git checkout commands to remove the existing files and retrieve them from the repository again with the correct line endings. BEFORE doing this ensure you commit any local changes as anything not committed will be lost.

    $ git reset --hard HEAD
    $ git checkout .
    

    Failing this, you could try setting ‘core.eol’ to lf, which ensures all files in the repository have LF line endings.

    $ git config core.eol lf
    

    Hopefully this works. Even if it does, it’s good practice to ensure that your repository files have consistent line endings. You could use git ls-files --eol to list line endings of all files and then use a conversion command if needed.

    Login or Signup to reply.
  2. 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
    
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search