How to fix warning: LF will be replaced by CRLF in file.txt. The file will have its original line endings in your working directory in Git

What this error means

The "LF will be replaced by CRLF" warning tells you that Git is automatically converting line endings in your files. This happens because: **LF (Line Feed, \n)** is the Unix/Linux/macOS line ending standard. **CRLF (Carriage Return + Line Feed, \r\n)** is the Windows line ending standard. When `core.autocrlf` is set to `true` (the default on Windows Git installations), Git performs automatic conversions: - **On checkout**: Converts LF to CRLF so files work correctly in Windows editors - **On commit**: Converts CRLF back to LF to keep LF in the repository This warning appears when you add or stage a file that has LF endings and Git is going to convert it to CRLF in your working directory. The message "The file will have its original line endings in your working directory" is somewhat confusing - it actually means the file you're committing will be stored with LF in the repository, while your local copy will be converted to CRLF. This is not an error, but a notification that automatic line ending conversion is happening. For many projects, especially those with developers on different operating systems, consistent line endings are important to avoid: - Merge conflicts caused purely by line ending differences - Diffs showing entire files as changed when only line endings differ - Build or script failures on systems expecting specific line endings

Typical symptoms

• Warning appears when running 'git add' on Windows
• Warning shows for files created on Linux/macOS or downloaded from the web
• Multiple warnings appear when cloning repositories from Unix systems
• Bash scripts or shell files show this warning
• Warning appears after editing files in certain editors that use LF by default
• CI/CD builds show line ending warnings or failures
• Diff tools show entire files as changed with no visible content changes

Common causes

1. core.autocrlf is set to 'true' and files have LF line endings
2. Files were created on Unix/Linux/macOS and are being added on Windows
3. Editor is configured to use LF line endings by default (VS Code, Sublime, etc.)
4. Repository was cloned from a Unix-based system without .gitattributes
5. Project lacks a .gitattributes file to standardize line endings
6. Downloaded files from the internet often have LF endings
7. Copy-pasting code from web sources may introduce LF endings
8. Docker containers or WSL create files with LF on Windows filesystem

How to fix "warning: LF will be replaced by CRLF in file.txt. The file will have its original line endings in your working directory"

git config --global core.autocrlf

# Add files verbosely to see warnings
git add -v .

git config --global core.autocrlf true

git config --global core.autocrlf input

git config --global core.autocrlf false

# Create the file in your repository root
touch .gitattributes

# Set default behavior to automatically normalize line endings
* text=auto

# Explicitly declare text files you want to be normalized
*.c text
*.h text
*.cpp text
*.hpp text
*.py text
*.js text
*.ts text
*.json text
*.xml text
*.yml text
*.yaml text
*.md text
*.txt text
*.css text
*.html text
*.sh text eol=lf
*.bash text eol=lf

# Declare files that should always have CRLF line endings on checkout
*.bat text eol=crlf
*.cmd text eol=crlf
*.ps1 text eol=crlf

# Declare binary files that should not be modified
*.png binary
*.jpg binary
*.jpeg binary
*.gif binary
*.ico binary
*.pdf binary
*.zip binary
*.gz binary
*.tar binary
*.exe binary
*.dll binary
*.so binary
*.dylib binary

git add .gitattributes
git commit -m "Add .gitattributes for consistent line endings"

git stash

git rm --cached -r .

git reset --hard

git add .

git status
# You'll see files that had their line endings normalized

git commit -m "Normalize line endings"

git stash pop

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

{
  "default_line_ending": "unix"
}

# .editorconfig
root = true

[*]
end_of_line = lf
insert_final_newline = true
charset = utf-8

[*.{bat,cmd,ps1}]
end_of_line = crlf

git config --global core.safecrlf false

git add . 2>/dev/null

# Using sed
sed -i 's/\r$//' filename.txt

# Using dos2unix (install if needed: apt install dos2unix)
dos2unix filename.txt

# Using tr
tr -d '\r' < filename.txt > filename.tmp && mv filename.tmp filename.txt

dos2unix filename.txt

# Or using sed
sed -i 's/\r$//' filename.txt

(Get-Content filename.txt -Raw) -replace "\r\n", "\n" | Set-Content filename.txt -NoNewline

# Using unix2dos
unix2dos filename.txt

# Using sed
sed -i 's/$/\r/' filename.txt

# Find and convert all text files to LF
find . -type f -name "*.txt" -exec dos2unix {} \;
find . -type f -name "*.sh" -exec dos2unix {} \;

Advanced notes

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

* text=auto

# Always use LF (for shell scripts)
*.sh text eol=lf

# Always use CRLF (for Windows batch files)
*.bat text eol=crlf

# Never convert (treat as binary)
*.png binary

# Force text handling even if binary chars detected
*.svg text

/bin/bash^M: bad interpreter: No such file or directory

# Show line ending type
file filename.txt
# Output: "filename.txt: ASCII text" (LF) or "ASCII text, with CRLF line terminators"

# Show actual bytes (look for 0d 0a = CRLF)
hexdump -C filename.txt | head

# Count line ending types in a file
cat filename.txt | od -c | grep -c '\r'

Frequently asked questions

What does "warning: LF will be replaced by CRLF in file.txt. The file will have i" mean?

The "LF will be replaced by CRLF" warning tells you that Git is automatically converting line endings in your files. This happens because: LF (Line Feed, \n) is the Unix/Linux/macOS line ending standard. CRLF (Carriage Return + Line Feed, \r\n) is the Windows line ending standard.

How do I fix "warning: LF will be replaced by CRLF in file.txt. The file will have i"?

This Git warning appears on Windows when files have Unix-style line endings (LF) but Git is configured to convert them to Windows-style (CRLF). While not an error, this indicates a line ending configuration mismatch that can cause issues in cross-platform projects. Configure core.autocrlf appropriately or use .gitattributes for consistent handling.

What causes "warning: LF will be replaced by CRLF in file.txt. The file will have i"?

core.autocrlf is set to 'true' and files have LF line endings Files were created on Unix/Linux/macOS and are being added on Windows Editor is configured to use LF line endings by default (VS Code, Sublime, etc.)

Is the "warning: LF will be replaced by CRLF in file.txt. The file will have i" error serious?

It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Related errors

• bash: git: command not found

  How to fix "bash: git: command not found" in Git

  LOW

• error: cannot stat 'file.txt': Permission denied (possibly blocked by antivirus)

  How to fix 'Permission denied (possibly blocked by antivirus)' in Git

  MEDIUM

• fatal: renaming 'File.txt' failed: Invalid argument (case-insensitive filesystem)

  How to fix 'fatal: renaming failed: Invalid argument' on case-insensitive filesystem in Git

  MEDIUM

• fatal: Could not read from remote repository. 'git-upload-pack' command not found

  git-upload-pack command not found on remote server

  MEDIUM

• API rate limit exceeded

  How to fix 'API rate limit exceeded' in GitHub

  MEDIUM

• fatal: destination path already exists and is not an empty directory

  Destination Path Already Exists and Is Not Empty

  LOW

Official resources & further reading

• 📚Git Official Documentation
• 📖
  Git Configuration - core.autocrlf - Official Git Documentation(Official Docs)
• 📖
  gitattributes - End-of-line conversion - Git Documentation(Official Docs)
• 💬
  LF will be replaced by CRLF - What is that and is it important? - Stack Overflow(Stack Overflow)
• 📖
  CRLF vs LF: Normalizing Line Endings in Git(Official Docs)
• 📖
  Configuring Git to handle line endings - GitHub Docs(Official Docs)