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