chore: normalize line endings to LF

[joaodinissf]

Summary

Normalize all text files in the repo to LF line endings, stored as LF in the repo and checked out as LF on every platform. Fixes a long-standing historical accident.

What changes

• .gitattributes rewritten from the broken text eol=crlf (one line, no pattern — applied to a file literally named text that does not exist, so it was a no-op) to:

  * text=auto eol=lf
  
  *.bat text eol=crlf
  *.cmd text eol=crlf
  *.ps1 text eol=crlf
  

• git add --renormalize . run on top to apply the new rule to the existing tree.
• Windows-only scripts (.bat, .cmd, .ps1) stay CRLF since the Windows shell genuinely requires it. The repo has none today, but the exception is future-proofing.
• text=auto lets Git autodetect binary files via null-byte scanning; binaries (.gif, .png, .jar, etc.) are untouched. Verified: a whitespace-ignored diff of the commit shows only .gitattributes as a content change — the rest is pure EOL churn.

Why now

Current CRLF endings are a historical accident from Windows/Eclipse editors, not an enforced policy (the prior .gitattributes was effectively a no-op). LF is the standard in modern cross-platform tooling. Keeping CRLF introduces ^M noise in diffs, confuses POSIX tools (grep, sed, patch), and makes stray LF-only additions from Unix editors trivially corrupt the convention — which is how we ended up here.

How collaborators handle open branches

When this merges, branches cut from pre-normalization master will look like they changed every line of every text file. Don't panic — rebase, don't merge, and let merge.renormalize do the heavy lifting.

For branch authors (the common path)

git config merge.renormalize true          # one-time, per clone
git fetch upstream master
git rebase upstream/master                 # NOT `git merge`
git push origin <branch> --force-with-lease

Why merge.renormalize=true: tells Git to run text files through the current .gitattributes filter during 3-way merge. Without it, rebase thinks every file changed 100% of its lines (CRLF vs LF) and yells about phantom conflicts. With it, Git reconciles normalization and only flags real content conflicts.

Why rebase not merge: merging this commit into a CRLF branch creates a giant merge commit with ~946k lines of churn on both sides. Rebase walks your real commits onto the normalized base and re-applies them as LF — clean history.

Expected outcome

Most branches: no real conflicts, rebase applies cleanly.

If someone intentionally committed CRLF content (a test fixture that verifies line-ending handling, say), Git will flag it — rare in this codebase.

Windows devs — one-time local setup

git config --global core.autocrlf false    # recommended: LF in working tree too

Leaving core.autocrlf=true (Windows default) is harmless — checkout converts LF→CRLF, commit converts back. Just causes ^M noise in some editors. Set to false if you want parity with the repo.

Don't do

• Don't merge the normalization commit into a feature branch — rebase instead.
• Don't cherry-pick across the normalization boundary without merge.renormalize=true — same phantom-conflict storm as merge.
• Don't use an editor that silently converts line endings during the transition — VS Code, IntelliJ, modern Eclipse all respect .gitattributes.

Verification

# Before commit: whitespace-ignored diff should be EOL-only
git diff --cached -w --stat
# Result: 1 file changed (.gitattributes), rest was pure EOL normalization.

# Spot-check: binaries unchanged
git diff --cached --name-only | grep -iE '\.(gif|png|jpg|jar)$'
# Result: empty — Git correctly skipped binaries.

🤖 Generated with Claude Code