warning: in the working copy of 'app.sh', LF will be replaced by CRLF the next time Git touches it is a notice, not a failure: the file was added, and the repository stores it with LF line endings. Git is telling you that, because core.autocrlf is true, your working copy of the file will get Windows CRLF endings the next time Git writes it.

If that is fine for you, ignore it. If the file must keep LF on disk (shell scripts, files used inside Docker or WSL), add a .gitattributes file with * text=auto eol=lf and add the files again; the warning goes away.

The error

> git add app.sh
warning: in the working copy of 'app.sh', LF will be replaced by CRLF the next time Git touches it

Why it happens

With core.autocrlf=true Git normalises text files to LF when they go into the repository and converts them to CRLF when it writes them into your working folder. A file you create yourself with LF endings breaks that pattern: it goes in as LF, which is what Git wants, but the copy on your disk does not match what Git would write there. Git warns you because the next checkout, reset or branch switch that rewrites the file will quietly change its line endings.

The setting often comes from the line-ending page of the Git for Windows installer, which writes its choice to the system-wide config. Run git config --show-origin core.autocrlf to see which file sets it. On the machine used for this post the system config said false, so the test repository set true locally to produce the warning. After a commit, moving the file aside and restoring it with git checkout -- app.sh showed exactly what the warning predicted: git ls-files --eol reported i/lf w/crlf, LF in the repository and CRLF on disk.

The fix

> git rm -q --cached app.sh
> type .gitattributes
* text=auto eol=lf
> git add .gitattributes app.sh
> git ls-files --eol
i/lf    w/lf    attr/text=auto eol=lf 	.gitattributes
i/lf    w/lf    attr/text=auto eol=lf 	app.sh

The .gitattributes line marks every file Git detects as text for normalisation and pins its working-copy ending to LF, which overrides core.autocrlf for those files. Unstaging the file and adding it again produced no warning, and git ls-files --eol shows LF both in the index (i/lf) and on disk (w/lf). Commit the .gitattributes file so everyone who clones the repository gets the same endings, whatever their own setting. The honest alternative is to accept the warning: nothing in the repository is wrong, only your local copy changes, and most Windows editors and tools read CRLF without trouble. Use a narrower rule, such as *.sh text eol=lf, if only some files need LF.

How it was reproduced

Git for Windows 2.45.2 on Windows 11, run from Windows PowerShell. A fresh test repository with git config core.autocrlf true set locally, and a file written with LF endings by [IO.File]::WriteAllText(path, "a`nb`n"); git add printed the warning. The fix was a .gitattributes file written the same way.

Frequently asked

Is 'LF will be replaced by CRLF' an error?
No. It is a warning and the git add succeeded. The repository stores the file with LF; only your working copy will get CRLF endings the next time Git writes the file.
How do I stop the LF will be replaced by CRLF warning?
Add a .gitattributes file with the line * text=auto eol=lf and add the files again, or set core.autocrlf to false or input if you do not want Git to convert line endings on your machine.
Should I use core.autocrlf true or .gitattributes?
Prefer .gitattributes, committed to the repository, because it applies to everyone who clones it. core.autocrlf is a per-machine setting and differs between developers.

More decoded errors in the Fixes category.