Mikkeli Matlock
94d41d5c8a
The previous commit wrote a literal carriage-return byte into a comment, where the text was meant to show the two characters backslash-r. Git's content sniffing treats a lone CR as a sign of binary data, so .gitattributes itself was classed -text (git ls-files --eol reported i/-text): the one file in the repository that the new LF policy could not normalise. The rules themselves were never affected - the byte sat inside a comment, and deploy.bat and the sources were already checking out with the intended endings. The comment now says "a trailing CR byte" in words. .gitattributes reports i/lf w/lf, and `git add --renormalize .` stages nothing else. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LU1NRL7fAaZTtFMTTPn2b1
21 lines
1.0 KiB
Plaintext
21 lines
1.0 KiB
Plaintext
# Line endings: LF in the repository and in every working tree, on every OS.
|
|
#
|
|
# This file is the policy, not each machine's git config. Git for Windows installs
|
|
# with core.autocrlf=true, which checks text out as CRLF; an attribute here beats
|
|
# that setting, so a fresh clone gets LF regardless of how its machine is set up.
|
|
#
|
|
# It matters beyond tidiness. tools/branding-sites.tsv is read line by line with
|
|
# `read`, and under CRLF every row's last field gained a trailing CR byte - so the
|
|
# branding checker reported all 29 sites as missing on Windows while passing on the
|
|
# Linux CI runner. text=auto leaves genuinely binary files alone.
|
|
* text=auto eol=lf
|
|
|
|
# Shell scripts are pinned explicitly as well: a strict POSIX sh (dash, CI
|
|
# containers) rejects a CRLF shebang outright rather than misbehaving quietly.
|
|
*.sh text eol=lf
|
|
|
|
# The exception. cmd.exe misparses LF-only batch files around labels and long
|
|
# lines, so these alone are checked out CRLF. The repository copy is still LF.
|
|
*.bat text eol=crlf
|
|
*.cmd text eol=crlf
|