Problem
This repository has no .gitattributes, so git applies no line-ending normalization. Whatever line endings a tool happens to write are what get committed, and they differ per machine and per editor.
Measured with git ls-files --eol on the current index:
|
files |
| LF |
29 |
| CRLF |
54 |
| mixed (both inside one file) |
4 |
Mixed-ending files are the worst of these: a single file containing both endings produces diffs where lines appear changed although only the invisible ending differs, and they make git blame unreliable.
Why it happens here
core.autocrlf is false at the system level (set by the Git-for-Windows install, "checkout as-is, commit as-is") and unset globally. With no .gitattributes either, nothing normalizes anything on the way into the object database.
Recommended fix
1. Add a .gitattributes at the repository root. This is the authoritative mechanism: it lives in the repo, travels to every clone, and applies to every contributor and to CI — unlike core.autocrlf, which is per-machine and invisible to everyone else. It also takes precedence over core.autocrlf.
A reasonable starting point:
# Normalize all text files to LF in the object database.
* text=auto eol=lf
# Files that must stay LF to run on Linux/macOS.
*.sh text eol=lf
Add *.bat/*.cmd as text eol=crlf if this repo ships any — those genuinely need CRLF on Windows. Adjust the rest to the languages actually present.
2. Then renormalize, as a separate commit.
git add --renormalize .
git commit -m "chore: normalize line endings"
Order matters: .gitattributes first, then renormalize. Renormalizing first just re-commits whatever the local core.autocrlf decides, and the work is repeated later.
3. Time it deliberately. The renormalize commit touches every affected file, so do it when the repo is quiet — it will conflict with anything in flight, and it makes a large, noisy diff that reviewers should be told to skip.
Note
A machine-wide git config --global core.autocrlf input is a useful safety net for repos that lack .gitattributes, but it is not a substitute: it only protects the machine that sets it, so a collaborator or CI runner without it still commits CRLF. The .gitattributes file is what actually fixes this for everyone.
Found while auditing line endings across the local repository set.
Problem
This repository has no
.gitattributes, so git applies no line-ending normalization. Whatever line endings a tool happens to write are what get committed, and they differ per machine and per editor.Measured with
git ls-files --eolon the current index:Mixed-ending files are the worst of these: a single file containing both endings produces diffs where lines appear changed although only the invisible ending differs, and they make
git blameunreliable.Why it happens here
core.autocrlfisfalseat the system level (set by the Git-for-Windows install, "checkout as-is, commit as-is") and unset globally. With no.gitattributeseither, nothing normalizes anything on the way into the object database.Recommended fix
1. Add a
.gitattributesat the repository root. This is the authoritative mechanism: it lives in the repo, travels to every clone, and applies to every contributor and to CI — unlikecore.autocrlf, which is per-machine and invisible to everyone else. It also takes precedence overcore.autocrlf.A reasonable starting point:
Add
*.bat/*.cmdastext eol=crlfif this repo ships any — those genuinely need CRLF on Windows. Adjust the rest to the languages actually present.2. Then renormalize, as a separate commit.
Order matters:
.gitattributesfirst, then renormalize. Renormalizing first just re-commits whatever the localcore.autocrlfdecides, and the work is repeated later.3. Time it deliberately. The renormalize commit touches every affected file, so do it when the repo is quiet — it will conflict with anything in flight, and it makes a large, noisy diff that reviewers should be told to skip.
Note
A machine-wide
git config --global core.autocrlf inputis a useful safety net for repos that lack.gitattributes, but it is not a substitute: it only protects the machine that sets it, so a collaborator or CI runner without it still commits CRLF. The.gitattributesfile is what actually fixes this for everyone.Found while auditing line endings across the local repository set.