Git is adding carriage returns to line endings in some files despite autocrlf being off

Question

I'm working on a repo in Windows. The repo was originally created on a mac and all files in it use LF only for line endings. When I clone the repo on another mac I see that all files have LF as the line ending. When I clone on Windows, some files, but not all, have the line endings as CRLF. core.autocrlf is set to false. There are no attributes on the files as checked with git check-attr -a foo. If I run:

git rev-parse HEAD:foo   # Outputs "abc123...abc"
git cat-file -p "abc123...abc" | xxd

Then I see the file with LF endings. (I installed xxd on windows to try and minimize tooling that could be introducing errors after discovering that git cat-file -p ... > temp.txt was changing the encoding to UTF-16)

git status shows that there are no changes to foo. If I convert the line endings in foo from CRLF to just LF, then git status shows that there are changes. Even though the file should only ever have had LF.

If I drop into WSL on Windows and run git status then it shows all the files with the errant CRs in them as being changed. "Git Bash" gives the same results as Windows however.

What on earth is going on? How do I make git stop changing my line endings?

Answer 1

What does it do if it isn't set? If you can add this as a dedicated answer

That is what is explained in "How line ending conversions work with git core.autocrlf between different operating systems"

It confirms that the default value for core.autocrlf is true on Windows.

╔═══════════════╦══════════════╦══════════════╦══════════════╗
║ core.autocrlf ║     false    ║     input    ║     true     ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => CRLF ║
║ git checkout  ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => CRLF ║ CRLF => CRLF ║
╠═══════════════╬══════════════╬══════════════╬══════════════╣
║               ║ LF   => LF   ║ LF   => LF   ║ LF   => LF   ║
║ git commit    ║ CR   => CR   ║ CR   => CR   ║ CR   => CR   ║
║               ║ CRLF => CRLF ║ CRLF => LF   ║ CRLF => LF   ║
╚═══════════════╩══════════════╩══════════════╩══════════════╝

Answer 2

First, double-check, from your repository local root folder, that your setting is set to "false":

git config --show-origin --get core.autocrlf

(When using Windows Subsystem for Linux (WSL), it is important to note that WSL has its own Git configuration separate from Windows. Ensure the configuration within WSL also has core.autocrlf set to false.)

Check also if there's a .gitattributes file in the repository. This file can override core.autocrlf settings. If it exists, look for any line that might be affecting line endings, like:

* text=auto

If such a line exists, it could be causing Git to automatically convert line endings. You might want to change it to:

* text=false

Or remove it altogether.

And run git add --renormalize . to apply the new directives.

Make sure the settings of your editor is not converting line endings on save.

Make also sure the .git/hooks directory does not include any pre-commit or post-checkout hooks that might be altering line endings.

Answer 3

As a diagnostic step that wouldn't fit as a comment, plus some comments to provide context for the step:

I'll be surprised if powershell isn't what's behind the unwanted UTF-16 conversion. The line endings act more like some sneaky attribute (but I see you did git check-attr -a so looking like not that) or filter processing.

Try running without any site overrides. Go in to your troubled clone and (I'm using bash, convert as needed but never let powershell touch any data you don't want it rewriting as it sees fit)

git clone --template= -ns . `mktemp -d`    # or `../deleteme` if you don't have mktemp
cd $_
git config core.autocrlf false
git config --system -l    # ok if this errors out
git config --get-regexp core
git checkout

Then check whethergit grep -l $'\r' lists files that git grep -l $'\r' @ doesn't. For a sample of any that do, comment with or edit into your question the git check-attr -a $thatfile results for that file, or if none do say that, and we'll do another round.