Git “CRLF Will Be Replaced by LF” Warning: What to Do

The warning CRLF will be replaced by LF the next time Git touches it means Git is applying a line-ending conversion rule. CRLF is the Windows-style line ending; LF is used by Unix-like systems. The message is usually informational, not a failed add or commit. Check the file’s attributes and repository settings before changing anything.

What the CRLF-to-LF warning means

A text line ends with either a line feed (LF, common on macOS and Linux) or a carriage return followed by a line feed (CRLF, common on Windows). Git can normalize text files to LF in its index while checking them out with the line endings configured for your working tree.

The exact warning and conversion depend on your Git configuration and any .gitattributes rules. It does not by itself mean your file is corrupted or that Git has lost changes. Inspect the staged diff and line-ending settings to confirm the result.

Check the repository’s line-ending rules

First see whether the file has an explicit text or end-of-line attribute, and what line endings Git sees in the index and working tree:

git check-attr text eol -- path/to/file
git ls-files --eol -- path/to/file

In git ls-files --eol output, i/ describes the index, w/ the working tree, and attr/ the applicable attribute. Then inspect the configured conversion option and where it came from:

git config --show-origin --get core.autocrlf

If that command prints no value, the setting may be unset; that is not an error by itself. Git can also use core.eol and attributes from .gitattributes. Repository attributes are usually the best place to document shared project policy.

Choose consistent line endings with .gitattributes

For a cross-platform project, a repository-level .gitattributes file can normalize text in Git while allowing the working tree to use native endings:

* text=auto
*.sh text eol=lf
*.bat text eol=crlf

This is an example, not a universal policy. Explicit rules are useful for scripts that require LF or Windows batch files that require CRLF. Consider generated, binary, and vendored files separately instead of assuming every file should be treated as text. Commit the rules so all contributors share them.

Renormalize tracked files only after reviewing the change

If you added or changed attributes and intend to apply them to existing tracked files, Git can refresh their index entries:

git add .gitattributes
git add --renormalize .
git diff --cached --check
git diff --cached --stat
git diff --cached

Review the staged diff before committing. A line-ending normalization can touch many files, and a broad staged change may make code review harder. If it is unexpectedly large, stop and inspect the attributes and configuration instead of committing it blindly.

Should you disable the warning?

Usually, do not disable conversion just to hide the message. First decide which line endings the repository should store and which the working tree should use. Then use consistent .gitattributes rules or a deliberate local Git configuration that matches that policy.

Avoid changing global Git settings for a warning in one repository without understanding the impact on your other projects. If you only need to confirm whether a conversion created a noisy diff, inspect git diff and the output of git ls-files --eol before making the change.

Common questions

Is “CRLF will be replaced by LF” an error?

In most cases it is a warning about the line-ending conversion Git will apply. Confirm with git status and git diff --staged; the warning alone does not mean the add failed.

Should Git store LF or CRLF?

Many cross-platform repositories normalize text to LF in the index and specify exceptions for files that need another format. The appropriate policy depends on the project and its tools, so encode it in repository attributes and verify it with the team.