core.autocrlf=false stopped working

[OurMajesty]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

git version 2.51.0.windows.2
cpu: x86_64
built from commit: ade1f1c136682d1bed178d573dc4dc40dca11623
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.16.0
OpenSSL: OpenSSL 3.5.3 16 Sep 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.26100.6725]

Options set during installation

Editor Option: VisualStudioCode
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable FSMonitor: Disabled

Other interesting things

For some reason, core.autocrlf=false stopped working. I noticed this recently due to error highlighting in the IDE, as well as "LF will be replaced by CRLF the next time Git touches it" messages in a previously cloned repository. I hadn't noticed such problems before. I tried downgrading all the way back to version 2.50, but found the same behavior there. It's worth noting that the core.autocrlf=input value works as expected.
core.autocrlf=false:

core.autocrlf=input:

Terminal/shell

CMD

Commands that trigger the issue

git clone, git pull, etc.

Expected behaviour

no conversion of line-endings when core.autocrlf set to false

Actual behaviour

when core.autocrlf set to false cloned repo files have crlf endings

Repository

No response

[tboegi]

Are you sure that this is a regression ?
That code hasn't changed.
And what you describe, is the expected behviour.

More important:
...when core.autocrlf set to false cloned repo files have crlf endings..
unless you set core.eol=lf

[OurMajesty]

Turns out this isn't a bug per se, but a .gitattributes behavior (text=auto).
According to info from this commit, setting core.autocrlf to false does not override core.eol parameter, which is in turn used for normalization caused by text=auto

But when I remove text=auto from .gitattributes, cloning still results in crlf.
While digging deeper, I discovered that when the .gitattributes file is missing from the repository, normalization doesn't occur.
Also, when .gitattributes doesn't contain any mention of eol for specific cases (regardless of the value), normalization also doesn't occur.
Maybe this is a bug then? Or missing documentation.

The solution was to add text eol=lf for all files, not removing it entirely.