Fix Git "warning: LF will be replaced by CRLF" on Windows

TL;DR — Quick Fix

Run this once to silence the warning and handle line endings correctly on Windows:

git config --global core.autocrlf true

On a cross-platform team? Or does the warning keep coming back from specific files? Use a .gitattributes file — covered below.

Why This Warning Appears

Windows line endings are CRLF (\r\n). Linux and macOS use LF (\n). When you clone or stage files that contain LF-only endings on Windows, Git warns you it's converting them to CRLF for your working directory.

The warning is harmless — no data is lost. But it's noisy. Worse, if autocrlf is misconfigured, files will show up as "changed" on every git status even when you haven't touched a single line.

The root setting is core.autocrlf:

• true — Git converts LF→CRLF on checkout, CRLF→LF on commit (the standard Windows setting)
• input — converts CRLF→LF on commit only, no conversion on checkout (good for WSL or Linux-targeting devs on Windows)
• false — no conversion at all (you manage line endings yourself)

Fix 1: Set core.autocrlf Globally (simplest)

Most Windows developers working on Windows-native projects want this:

git config --global core.autocrlf true

Targeting Linux servers, or working inside WSL? Use input instead:

git config --global core.autocrlf input

To see what's currently set:

git config --global core.autocrlf

Fix 2: Use .gitattributes (recommended for teams)

Global config solves the problem on your machine. But every teammate needs the right setting too — and that's where it breaks down. A .gitattributes file enforces line endings at the repo level, regardless of what anyone has in their global config.

Create .gitattributes in your repo root:

# Auto-detect text files and normalize to LF in the repo
* text=auto

# Force LF for scripts and source files
*.sh text eol=lf
*.py text eol=lf
*.js text eol=lf
*.ts text eol=lf
*.json text eol=lf
*.md text eol=lf
*.yml text eol=lf
*.yaml text eol=lf

# Force CRLF for Windows-only files
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf

# Binary files — no conversion
*.png binary
*.jpg binary
*.gif binary
*.ico binary
*.zip binary
*.exe binary

Commit this file and push. Git will enforce these endings for the whole team — no per-developer setup required.

Fix 3: Normalize an Existing Repo

Already have mixed line endings in your repo? Clean them up in two steps:

# Step 1: Add .gitattributes first
git add .gitattributes
git commit -m "Add .gitattributes for line ending normalization"

# Step 2: Remove all cached files and re-add with correct endings
git rm --cached -r .
git reset --hard
git add .
git commit -m "Normalize line endings across repo"

Step 2 forces Git to re-process every tracked file through the new .gitattributes rules. Line endings in the repo history before this commit are untouched — but everything going forward will be consistent.

Fix 4: Suppress the Warning Without Changing Behavior

Already handling line endings via .gitattributes and just want cleaner output? You can silence the warning directly:

git config --global core.safecrlf false

Or keep it at warn (the default) rather than true, which blocks commits that contain mixed endings:

git config --global core.safecrlf warn

Only reach for this after you've sorted out line endings elsewhere. It's a mute button, not a fix.

Verify the Fix

Check your global config:

git config --global --list | grep -i crlf

Expected output (for the true setting):

core.autocrlf=true

Want to inspect a file's actual line endings?

# Git Bash
file yourfile.txt
# Output: yourfile.txt: ASCII text, with CRLF line terminators

# PowerShell
(Get-Content yourfile.txt -Raw) -match "\r\n"

After staging files with the updated config, run git status. If nothing shows as modified — and you haven't actually changed any content — line endings are stable.

When the Warning Keeps Appearing After the Fix

• Repo-level config overrides global — Run git config --local core.autocrlf inside the repo. A local setting in .git/config silently overrides whatever you set globally.
• .gitattributes conflict — A rule with eol=lf on a file that still has CRLF in your working directory will keep triggering. Force re-normalization with git rm --cached <file>, then git add <file>.
• Editor writing CRLF on save — VS Code: add "files.eol": "\n" to your settings. Notepad++ has a similar option under Edit → EOL Conversion.

Recommended Setup for Most Teams

• Add a .gitattributes with * text=auto as the baseline rule.
• Windows developers set git config --global core.autocrlf true.
• Mac/Linux developers set git config --global core.autocrlf input.

Net result: the repo always stores LF. Windows developers get CRLF in their working directory. Mac and Linux developers get LF. No surprises across platforms.