chore: add .gitattributes -- no line-ending normalization, CRLF and mixed endings already committed

Start at the repository root and inspect the current file endings with git ls-files --eol. Add .gitattributes using the issue's proposed rules, then create the renormalization as a separate commit with git add --renormalize .; done means the attributes file is committed first and the resulting line-ending changes are isolated for review.

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:

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.