If Git prints warning: LF will be replaced by CRLF the next time Git touches it on Windows, it can look like something has gone wrong. In most cases, Git is explaining how it will handle line endings—not reporting a failed command. The message comes from differences between Unix-style LF endings and Windows-style CRLF endings.
This guide explains what the LF-to-CRLF warning means, how Git's core.autocrlf setting works, and how to choose a consistent line-ending policy for a Windows development environment and a team repository.
What does “LF will be replaced by CRLF” mean in Git?
A text file ends each line with a line-ending character. Linux and macOS commonly use the line-feed (LF) ending; Windows programs commonly use the carriage-return plus line-feed (CRLF) ending. Git can normalize text files so the repository stores LF while your Windows working directory uses CRLF.
With core.autocrlf=true, Git normally converts LF line endings in the repository to CRLF in your Windows working tree, and converts CRLF back to LF when staging text files. The warning tells you that a file currently containing LF may be checked out or rewritten with CRLF under that policy. It is usually informational. If the command itself exits with an error or files appear unexpectedly changed, check the repository status and settings below.
Step 1: Check your Git line-ending settings
First inspect the setting that applies to your repository:
git config --show-origin --get core.autocrlfNo output means no value is set at the checked configuration levels; Git may use its default behavior or an attribute rule. Also check any repository-specific attributes and pending changes:
git status --short
git check-attr text eol -- path/to/file.txtReplace path/to/file.txt with the affected file. A value set locally in the repository can override a global preference, so --show-origin helps identify where the active value came from.
Step 2: Choose the right core.autocrlf value on Windows
Option A: Use true for a typical Windows workstation
This is a common choice when you want CRLF in your Windows working copy while keeping normalized LF in Git commits:
git config --global core.autocrlf trueTo apply it only to the current repository, run the command from inside that repository and omit --global:
git config core.autocrlf trueOption B: Use false when the repository defines line endings
If your project uses a committed .gitattributes file to set line endings, you can disable Git's broad automatic conversion and let those rules describe the files:
git config --global core.autocrlf falseCoordinate this choice with your team. Without suitable attributes, files may retain whatever line endings editors or tools write.
Option C: Use input to normalize on commit only
input converts CRLF to LF when content is staged but does not convert LF to CRLF when files are checked out. It is more common on Unix-like systems, but may suit a Windows workflow when you specifically want LF in the working tree too:
git config --global core.autocrlf inputAfter changing a setting, verify the value and review your working tree:
git config --show-origin --get core.autocrlf
git status --shortStep 3: Set consistent rules with .gitattributes
For a shared project, a committed .gitattributes file is often the clearest way to define line endings for everyone, regardless of operating system. For example:
# Detect text files and normalize them to LF in the repository
* text=auto
# Keep shell scripts LF so they work on Unix-like systems
*.sh text eol=lf
# Use CRLF for common Windows scripts
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlfAdapt these rules to your project. Explicit file-specific rules make the expected checkout format clear and take precedence over general automatic conversion. Binary files should not be treated as text; Git's automatic detection or explicit rules such as *.png -text can help keep them unchanged.
When adding or changing attributes in an existing repository, review and back up or commit any work you need to keep. Then normalize tracked files with:
git add --renormalize .
git status --shortReview the diff carefully before committing. Renormalization can make many text files appear changed because their repository representation is being standardized.
How to prevent LF and CRLF conflicts
- Commit a
.gitattributesfile so the whole team follows the same rules. - Keep editor settings consistent with the project; many editors can honor
.editorconfig. - Check
git statusbefore and after changing line-ending settings. - Avoid mixing line-ending conversions with unrelated code edits in one commit.
- Do not repeatedly switch
core.autocrlfvalues in the middle of active work. - Inspect a diff with
git diff --ignore-space-at-eolwhen you suspect a line-ending-only change; still review the normal diff before committing.
Frequently asked questions
Is “LF will be replaced by CRLF” a fatal Git error?
Usually no. It is a warning about a future line-ending conversion. Check the command's exit status and git status if the operation seems to have failed.
Will changing core.autocrlf rewrite my files immediately?
Changing the setting changes Git's conversion behavior, but it does not automatically make every existing working file match the new policy. Use .gitattributes and a planned renormalization when a repository-wide correction is needed.
Which setting should I use for a team project?
Use the repository's documented policy. A committed .gitattributes file provides a shared rule; individual developers should avoid conflicting local settings that undermine it.
Conclusion
The Git message “LF will be replaced by CRLF” on Windows usually reflects Git's line-ending conversion policy, not lost work. For a typical Windows setup, git config --global core.autocrlf true is a common choice. For a team, defining file-specific rules in .gitattributes is more predictable. Check your active configuration, protect uncommitted work, and review diffs after any line-ending change to keep Git commits clean across Windows, macOS, and Linux.
0 Comments