From 5212b7806bbf01413d624e8a98a5a6b9c4d7e8a8 Mon Sep 17 00:00:00 2001 From: Mikkeli Matlock Date: Mon, 14 Sep 2026 01:41:39 +0900 Subject: [PATCH] fix: remove a stray CR byte from .gitattributes 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 template that the new LF policy could not normalise, and one every repo created from it would have inherited. The rules themselves were never affected - the byte sat inside a comment. 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 Claude-Session: https://claude.ai/code/session_01LU1NRL7fAaZTtFMTTPn2b1 --- .gitattributes | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.gitattributes b/.gitattributes index a6266de..c58c7cb 100644 --- a/.gitattributes +++ b/.gitattributes @@ -5,7 +5,7 @@ # 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 - so the +# `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