Git “LF will be replaced by CRLF”: normalize line endings deliberately
It is usually harmless: Git stores LF and checks out CRLF on Windows. Silence it deliberately with .gitattributes.
Usually safe to ignore: Git keeps LF in the repository and gives you CRLF on Windows. To make it consistent for everyone, add a .gitattributes with text=auto instead of relying on each machine's settings.
Try these fixes in order
Inspect the autocrlf setting
Check the current setting and where it comes from. On Windows true is common; on macOS and Linux input is the usual choice.
git config --show-origin core.autocrlfDeclare line endings in .gitattributes
Add a .gitattributes at the repo root declaring text handling per file type, for example * text=auto for automatic normalization, or *.sh text eol=lf to force LF for shell scripts. Commit the file.
printf '* text=auto\n*.sh text eol=lf\n' > .gitattributesRenormalize once, in its own commit
Normalize the repository in a dedicated commit with git add --renormalize ., then review git status to confirm only line-ending changes are staged.
git add --renormalize .git status --short | headVerify the warning is gone
After the normalization commit, the warning disappears for covered files and every machine gets consistent endings regardless of local autocrlf.
Interpret what you see
The message says "warning", and commits still succeed
What it suggests: This is a warning, not an error. Git will convert line endings on checkout/commit; the file's committed bytes keep LF.
Next check: No action needed if your team is fine with CRLF working copies on Windows and LF in the repo.
Diffs show whole-file changes on some machines only
What it suggests: Different developers see different line endings because each machine's core.autocrlf setting differs.
Next check: Run git config --show-origin core.autocrlf on each machine and compare.
The warning persists after aligning autocrlf settings
What it suggests: A .gitattributes rule already forces an eol style that conflicts with the local autocrlf setting.
Next check: Check .gitattributes for text, eol, or -text rules affecting the file.
Why this happens
- core.autocrlf is enabled, typically true on Windows, so Git converts LF to CRLF in the working tree on checkout and back on commit.
- The repository has no .gitattributes, so line-ending behavior depends on each developer's local Git configuration.
Still not working?
Do not normalize a whole repository's line endings in the same commit as real changes; it rewrites every line and destroys blame history. Do the renormalization in its own dedicated commit, and prefer .gitattributes over per-machine autocrlf settings.
Official sources
These steps are based on the linked documentation and general diagnostics. BugMedic has not independently tested every product and system configuration. Review commands before running them.