“LF will be replaced by CRLF”: line endings in git, explained
Windows ends each line of text with two invisible characters, everything else with one. Git is telling you it will quietly convert between them, which is usually fine and occasionally breaks scripts.
What LF and CRLF are
A line break is a character too. Linux and macOS use LF (line feed, \n, byte 0A). Windows uses CRLF (carriage return then line feed, \r\n, bytes 0D 0A), a leftover from typewriters, where the carriage went back and the paper moved up. Editors hide the difference, but programs, diffs and hashes see it: two files that look identical can have different hashes (check with the hash generator), and a diff can show every line as changed.
What git is warning about
warning: in the working copy of 'app.js', LF will be replaced by CRLF the next time Git touches itThis means core.autocrlf is true (the Git for Windows default): files are stored in the repository with LF and turned into CRLF in your working folder. Nothing is broken. The reverse warning, CRLF will be replaced by LF, means a file on disk has CRLF and git will store LF.
The settings, in plain words
| core.autocrlf | On commit | On checkout | Typical for |
|---|---|---|---|
true | CRLF to LF | LF to CRLF | Windows |
input | CRLF to LF | unchanged | macOS, Linux |
false | unchanged | unchanged | when .gitattributes decides |
The fix that works for the whole team
Personal settings differ per machine, so put the rule in the repository. Create .gitattributes:
* text=auto eol=lf
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf
*.png binary
*.jpg binaryThen convert files already committed and check the result:
git add --renormalize .
git status # shows files whose endings changed
git commit -m "Normalise line endings"Most editors can also be told to save with LF (VS Code: the CRLF/LF button in the status bar, or "files.eol": "\n"), and an .editorconfig with end_of_line = lf covers many editors at once.
Symptoms of wrong line endings
/bin/bash^M: bad interpreter: No such file or directoryor$'\r': command not found: a shell script saved with CRLF. Fix withsed -i 's/\r$//' script.shordos2unix script.sh, and add*.sh text eol=lf.^Mat the end of lines ingit diffor vim: mixed endings in one file.- A pull request where every line changed but nothing visible did. Paste both versions into a text diff to confirm only whitespace differs, then renormalise.
- Docker images built on Windows whose entrypoint script “doesn’t exist”: the same
^Mproblem.
Script failing with Permission denied rather than bad interpreter? See ./script.sh: Permission denied.
Questions
Is “LF will be replaced by CRLF” an error?
No, it's a warning. Git is telling you that, because core.autocrlf is on, it will convert line endings in your working copy. Your commit still succeeds.
How do I stop the LF will be replaced by CRLF warning?
Commit a .gitattributes file such as '* text=auto eol=lf', run git add --renormalize . once, and commit. Then every clone uses the same endings and the warning stops. Setting core.autocrlf to false also silences it, but only on your machine.
Should I use LF or CRLF?
LF for almost everything, including code that runs on Windows. Keep CRLF only for Windows batch and PowerShell files that need it. Modern Windows editors handle LF fine.
What does ^M mean in my file?
It is the carriage return character (CR) left over from Windows line endings. Shell scripts with ^M fail with 'bad interpreter'; remove them with dos2unix or sed -i 's/\r$//' file.
Published .