Skip to content

Windows checkouts show hundreds of phantom-modified files: no eol policy in .gitattributes, so autocrlf + prettier's lf default fight each other #1940

Description

@olaservo

Version: v2 (main)
Affected client: repo tooling / contributor DX (Windows)

Symptom

On a Windows clone with core.autocrlf=true (the Git-for-Windows default), a fresh pull checks every text file out with CRLF. The first npm run format then rewrites every file prettier touches to LF (prettier's default endOfLine: "lf"; the repo sets no override), after which git status reports hundreds of files modified — 934 after pulling the v2.0 release — with zero real content changes (git diff --numstat shows 0/0 for all of them; git normalizes eol on staging so nothing can actually be committed). Every Windows contributor gets this churn plus a wall of LF will be replaced by CRLF warnings on every git operation.

Root cause

.gitattributes carries no end-of-line policy (it only has the package-lock.json linguist-generated entry), so working-copy eol is left to each machine's core.autocrlf, which on Windows directly contradicts what prettier enforces.

Suggested fix

Declare the policy in-repo so it wins over local git config:

* text=auto eol=lf

plus a one-time git add --renormalize . commit if any CRLF blobs exist in history. This makes every platform check out LF, matching prettier, and the phantom-modification class disappears. (Binary globs like *.png are auto-detected by text=auto, but can be listed explicitly if preferred.)

Context

Hit while working #1852 on a Windows machine, immediately after pulling the release.

Metadata

Metadata

Assignees

Labels

v2Issues and PRs for v2

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions