Summary
The repository has no .gitattributes, so the line endings that land in a commit depend entirely on each machine's core.autocrlf.
On the current development machine core.autocrlf is true, which normalises to LF on commit and checks out CRLF — the reason every git add prints:
warning: in the working copy of '<file>', LF will be replaced by CRLF the next time Git touches it
That happens to match the project convention (~/.claude/CLAUDE.md: text files are UTF-8 without BOM, LF; CSV is UTF-8 with BOM, CRLF). But it is a machine setting, not a repository one. A clone on a machine with core.autocrlf=false or input would behave differently, and nothing in the repo would stop CRLF from being committed.
Why this is not being fixed without a decision
Adding .gitattributes is one small file, but the consequence is not small:
* text=auto eol=lf triggers a renormalisation pass. Depending on what is currently stored, that can produce a commit touching every text file in the repository, which is exactly the kind of history noise a linear single-developer repo does not want.
- It needs a decision on the CSV rule. The global convention says CSV is CRLF with BOM, which contradicts a blanket
eol=lf and needs its own pattern line.
- The checkout is inside a OneDrive-synced folder, where
.memory/testing.md already records fs.rmSync failing silently and git stash breaking. A mass re-write of every file in the working tree is worth doing deliberately rather than as a side effect.
Whether to pin this now, pin it without renormalising (text=auto only for new files), or leave it alone as a single-machine project is a maintainer call.
Suggested handling
If it goes ahead:
* text=auto eol=lf
*.csv text eol=crlf working-tree-encoding=UTF-8
*.png binary
*.jpg binary
*.mp4 binary
Then git add --renormalize . as its own commit, so the noise is isolated and reviewable in one place.
Acceptance criteria
- Line-ending policy is defined in the repository, not per machine.
- Any renormalisation lands as a single isolated commit.
- The CSV convention is preserved.
Summary
The repository has no
.gitattributes, so the line endings that land in a commit depend entirely on each machine'score.autocrlf.On the current development machine
core.autocrlfistrue, which normalises to LF on commit and checks out CRLF — the reason everygit addprints:That happens to match the project convention (
~/.claude/CLAUDE.md: text files are UTF-8 without BOM, LF; CSV is UTF-8 with BOM, CRLF). But it is a machine setting, not a repository one. A clone on a machine withcore.autocrlf=falseorinputwould behave differently, and nothing in the repo would stop CRLF from being committed.Why this is not being fixed without a decision
Adding
.gitattributesis one small file, but the consequence is not small:* text=auto eol=lftriggers a renormalisation pass. Depending on what is currently stored, that can produce a commit touching every text file in the repository, which is exactly the kind of history noise a linear single-developer repo does not want.eol=lfand needs its own pattern line..memory/testing.mdalready recordsfs.rmSyncfailing silently andgit stashbreaking. A mass re-write of every file in the working tree is worth doing deliberately rather than as a side effect.Whether to pin this now, pin it without renormalising (
text=autoonly for new files), or leave it alone as a single-machine project is a maintainer call.Suggested handling
If it goes ahead:
Then
git add --renormalize .as its own commit, so the noise is isolated and reviewable in one place.Acceptance criteria