How to fix warning: LF will be replaced by CRLF in file.txt in Git

GitBEGINNERLOWUpdated Dec 6, 2025· 361 views

This warning appears when Git detects line ending inconsistencies between your file and the repository's configured line ending style. It indicates Git will normalize line endings during commit or checkout based on your core.autocrlf setting.

Quick fix

Fixes warning: LF will be replaced by CRLF in file.txt

git config --get core.autocrlf
  1. Understand what the warning means
  2. Suppress the warning (quick fix)
  3. Configure core.autocrlf appropriately
  4. Use .gitattributes for project-wide consistency (recommended)
git — error
git config --get core.autocrlf
warning: LF will be replaced by CRLF in file.txt

What this error means

When Git displays `warning: LF will be replaced by CRLF`, it's telling you about automatic line ending conversion. This happens because Windows uses CRLF (Carriage Return + Line Feed, \r\n) for line endings, while Unix-based systems (Linux, macOS) use just LF (Line Feed, \n). The warning means Git is configured to convert line endings, and it's letting you know what will happen to your file. The direction of conversion depends on your `core.autocrlf` setting: - **On Windows with `core.autocrlf=true`**: Files are stored with LF in the repository but converted to CRLF in your working directory. The warning "LF will be replaced by CRLF" means Git will convert LF to CRLF when checking out the file. - **You might also see the reverse**: "CRLF will be replaced by LF" means Git will normalize CRLF to LF when committing. This is informational, not an error. Git is working as configured to handle cross-platform line ending differences automatically.

Typical symptoms

  • Warning appears when running git add on text files
  • Warning shows during git commit operations
  • Multiple warnings appear when adding many files at once
  • Warning mentions specific filenames that will have line endings converted
  • Warning appears after cloning a repository or switching branches
  • Different warnings appear on Windows vs Linux/macOS for the same repository

Common causes

  1. core.autocrlf is set to true (common on Windows Git installations)
  2. File was created on a different operating system with different line endings
  3. Editor or IDE saved the file with non-native line endings
  4. Repository has no .gitattributes file to enforce consistent line endings
  5. Mixing files from different sources with inconsistent line endings
  6. Git's default configuration on Windows enables automatic CRLF conversion

How to fix "warning: LF will be replaced by CRLF in file.txt"

1Understand what the warning means

First, recognize this is a warning, not an error. Git is telling you it will automatically handle line ending conversion. Check your current autocrlf setting:

bash
git config --get core.autocrlf

Common values:
- true: Convert LF to CRLF on checkout, CRLF to LF on commit (Windows default)
- input: Convert CRLF to LF on commit, no conversion on checkout (recommended for Unix)
- false: No automatic conversion

The warning appears because Git found a mismatch between the file's current line endings and what it will become after conversion.

2Suppress the warning (quick fix)

If you understand the conversion and just want to hide the warning, you can disable it:

bash
# Suppress the safecrlf warning
git config --global core.safecrlf false

Or suppress only in the current repository:

bash
git config core.safecrlf false

Note: This hides the warning but doesn't change how Git handles line endings.

3Configure core.autocrlf appropriately

Set the autocrlf value that matches your workflow:

For Windows users (recommended):

bash
git config --global core.autocrlf true

This converts LF to CRLF on checkout and back to LF on commit, keeping repository files with LF while your working copy uses Windows-native CRLF.

For Linux/macOS users (recommended):

bash
git config --global core.autocrlf input

This converts any CRLF to LF on commit but doesn't touch files on checkout.

To disable all conversion:

bash
git config --global core.autocrlf false

Use this if you want complete control or if your project handles line endings via .gitattributes.

4Use .gitattributes for project-wide consistency (recommended)

The best solution is to add a .gitattributes file to your repository root. This ensures everyone uses the same line ending settings regardless of their local Git configuration:

bash
# .gitattributes - normalize all text files
* text=auto

# Explicitly declare text files
*.txt text
*.md text
*.json text
*.xml text
*.html text
*.css text
*.js text
*.ts text
*.py text
*.sh text eol=lf
*.bat text eol=crlf

# Declare binary files
*.png binary
*.jpg binary
*.gif binary
*.ico binary
*.pdf binary
*.zip binary

The text=auto setting lets Git detect text files and normalize their line endings. Use eol=lf or eol=crlf to force specific endings for certain file types.

5Normalize existing repository line endings

If your repository already has mixed line endings, you can normalize them after adding .gitattributes:

bash
# Save any uncommitted changes first
git stash

# Remove all files from the index
git rm --cached -r .

# Re-add all files (this applies .gitattributes rules)
git reset --hard

# Check if there are changes to commit
git status

If Git shows modified files after this process, commit them:

bash
git add .
git commit -m "Normalize line endings"
6Handle specific files with different line endings

Some files need specific line endings regardless of the operating system:

Shell scripts should always use LF:

bash
# In .gitattributes
*.sh text eol=lf
*.bash text eol=lf
Makefile text eol=lf

Windows batch files should always use CRLF:

bash
# In .gitattributes
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf

This prevents issues where shell scripts fail on Unix because they have CRLF endings.

7Verify line endings in a file

To check what line endings a file currently has:

bash
# Using file command (Unix/macOS/Git Bash)
file myfile.txt

Output shows "CRLF line terminators" or "ASCII text" (LF).

bash
# Using cat -A to show special characters
cat -A myfile.txt | head -5

Lines ending with ^M$ have CRLF; lines ending with just $ have LF.

bash
# Using od (octal dump) for detailed view
od -c myfile.txt | head

Look for \r\n (CRLF) vs just \n (LF).

8Convert line endings manually

If you need to convert a file's line endings without relying on Git:

Using dos2unix/unix2dos:

bash
# Convert CRLF to LF
dos2unix myfile.txt

# Convert LF to CRLF
unix2dos myfile.txt

Using sed:

bash
# Convert CRLF to LF
sed -i 's/\r$//' myfile.txt

# On macOS
sed -i '' 's/\r$//' myfile.txt

Using tr:

bash
# Remove carriage returns
tr -d '\r' < input.txt > output.txt

Advanced notes

### Understanding the core.safecrlf Setting

The core.safecrlf setting controls whether Git warns about line ending conversions:

- true: Git will refuse to commit if the conversion would be irreversible
- warn: Git shows the warning but allows the commit (default when autocrlf is enabled)
- false: No warnings are shown

bash
git config --global core.safecrlf warn

### The Difference Between autocrlf Values

| Setting | On Commit | On Checkout | Best For |
|---------|-----------|-------------|----------|
| true | CRLF -> LF | LF -> CRLF | Windows users |
| input | CRLF -> LF | No change | Linux/macOS users |
| false | No change | No change | Manual control |

### Why .gitattributes is Better Than autocrlf

Using .gitattributes is preferred because:
1. It's checked into the repository, ensuring all contributors use the same settings
2. It allows per-file-type configuration
3. It doesn't depend on each developer's local Git configuration
4. It provides more granular control over which files are converted

### Handling Merge Conflicts from Line Endings

If you get merge conflicts that are only line ending differences:

bash
# Configure Git to ignore line endings in diff
git config merge.renormalize true

This tells Git to normalize line endings before comparing during merges.

### Windows Subsystem for Linux (WSL) Considerations

When using WSL, you might work on files from both Windows and Linux. Recommended settings:

bash
# In WSL
git config --global core.autocrlf input

# In Windows Git
git config --global core.autocrlf true

Or better yet, use .gitattributes to avoid confusion.

### Editor Configuration

Most modern editors can be configured to use specific line endings:

VS Code (settings.json):

json
{
  "files.eol": "\n"
}

EditorConfig (.editorconfig):

bash
[*]
end_of_line = lf

[*.bat]
end_of_line = crlf

Using EditorConfig with .gitattributes provides the most consistent experience across different editors and Git configurations.

Frequently asked questions

What does "warning: LF will be replaced by CRLF in file.txt" mean?
When Git displays warning: LF will be replaced by CRLF, it's telling you about automatic line ending conversion. This happens because Windows uses CRLF (Carriage Return + Line Feed, \r\n) for line endings, while Unix-based systems (Linux, macOS) use just LF (Line Feed, \n). The warning means Git is configured to convert line endings, and it's letting you know what will happen to your file.
How do I fix "warning: LF will be replaced by CRLF in file.txt"?
This warning appears when Git detects line ending inconsistencies between your file and the repository's configured line ending style. It indicates Git will normalize line endings during commit or checkout based on your core.autocrlf setting.
What causes "warning: LF will be replaced by CRLF in file.txt"?
core.autocrlf is set to true (common on Windows Git installations) File was created on a different operating system with different line endings Editor or IDE saved the file with non-native line endings
Is the "warning: LF will be replaced by CRLF in file.txt" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading