Git warns LF will become CRLF: inspect the index and working copy separately
By ON Lab · Sources checked November 8, 2026
The Git warning “LF will be replaced by CRLF” can describe a future working-copy conversion, not CRLF being stored in the commit. Inspect the file's index and working-copy endings with git ls-files --eol -- path, then inspect the path's attributes and relevant configuration. Do not change global settings merely to silence the message before checking the repository's intended policy.
The historical reader question asks why the warning's direction seems opposite to normalization into the repository. We reproduced that distinction using a disposable repository on macOS with an explicit CRLF working-copy policy. This tests Git's conversion behavior; it is not a test of the reader's old Windows Git build, editor or hosting service.
Keep the stored and working versions separate
Git can store normalized text in its index while writing different line endings in the working directory. Those are two representations of the same tracked text. A warning about what will happen when Git next writes the working copy does not establish that the index currently contains those same endings.
Begin with one affected tracked path, replacing sample.txt below:
git status --short
git ls-files --eol -- sample.txt
git check-attr text eol -- sample.txt
git config --show-origin --get core.autocrlf
git config --show-origin --get core.eol
git config --show-origin --get core.safecrlfRun the commands individually. An unset configuration key can return no value; do not mistake that for a completed diagnosis. The attribute check is path-specific, while configuration can come from several scopes. Read the actual outputs together rather than assuming your operating system alone determines the result.
Read the line-ending report
git ls-files --eol reports the index with an i/ field, the working-tree file with a w/ field, and relevant attributes with an attr/ field. The current Git reference describes the possible line-ending classifications, including LF, CRLF and mixed endings.
| Observation | Useful interpretation | Do not infer |
|---|---|---|
i/lf and w/lf | Both inspected representations currently use LF | That a future checkout must keep LF |
i/lf and w/crlf | The index and working copy currently use different endings | That the tracked text is necessarily corrupt |
A path-specific eol attribute | The path has an explicit line-ending rule to consider | That changing one global setting overrides every attribute |
| Mixed endings | The file needs closer inspection before normalization | That a blanket conversion is harmless |
The report is more informative than the warning alone because it describes the current file and index. Keep it with the command that produced the warning and that command's exit status.
What our controlled sequence showed
We created a text file whose bytes were one\ntwo\n, set the fixture's local core.autocrlf to true and core.safecrlf to warn, then staged the file. Git returned success and printed a warning that LF would become CRLF the next time it touched the working copy.
Immediately after staging, we inspected the actual file bytes: they still contained LF. The staged contents also contained LF. The warning had not rewritten the editable file at that point.
After committing the fixture, we made Git write a fresh working copy of that tracked file. Its bytes then contained CRLF, while the committed text remained normalized. Finally, we added a narrow fixture attribute, sample.txt text eol=lf, inspected it with git check-attr, and made Git write the file again. That working copy contained LF.
The file removals and checkouts used for this experiment were confined to a disposable repository. Do not delete and check out a real file just to imitate the test: that can discard work. The read-only inspection commands above are the starting point for an existing project.
Choose the project's policy before changing it
If LF on disk is required for a particular text path, the Git attributes documentation provides an explicit text and eol mechanism. Our narrow example demonstrates how a path rule can express that choice. It is not a recommendation to paste a catch-all rule over every file in an unfamiliar repository.
Inspect existing .gitattributes files and the project's contribution guidance first. Do not classify binary files as text just to remove a warning. Likewise, disabling a safety check is not the same as choosing and validating a line-ending policy.
A change to attributes can require a separate review of how already tracked files are normalized. This guide does not prescribe a whole-repository renormalization command. Review any proposed changes as a separate, bounded operation with the relevant files preserved.
Verify the intended result
- Read the affected path's effective attributes again after an intended policy change.
- Check the index and working-copy line-ending report separately.
- Inspect the staged diff before committing any normalization changes.
- Confirm that the consuming tool or script accepts the saved working file.
- Retain the warning and actual command result if they still disagree with the intended policy.
A warning can accompany a successful command, but a successful command does not prove that the chosen line endings suit every downstream tool. The useful outcome is a reviewed policy and verified bytes, not simply an empty terminal warning area.
If your issue is a file's upper- and lower-case name rather than its newline bytes, use the separate Git case-rename guide. Those changes require a different inspection and should not be mixed into a line-ending cleanup.