The 5-Second Fix
Tired of seeing this warning? Most Windows developers should simply tell Git to handle the conversion automatically. Run this command in your terminal:
git config --global core.autocrlf true
If you prefer to keep line endings exactly as they are (usually only if you work in a Windows-only environment), use this instead:
git config --global core.autocrlf false
What is actually happening?
This warning stems from a decades-old disagreement between operating systems on how to end a line of text. Every time you hit 'Enter,' a hidden character is saved.
- Windows uses CRLF (Carriage Return + Line Feed,
\r\n). This takes up 2 bytes per line break. - Linux and macOS use LF (Line Feed,
\n). This takes up only 1 byte.
Git was originally built for Linux, so it prefers LF. When you add a file created on a Mac to your Windows machine, Git notices the mismatch. It warns you that it will swap those LF characters for CRLF locally so your Windows editors don't break. However, the "source of truth" in the repository remains LF to keep things compatible for everyone.
Best Solutions for Developers
1. The "Set and Forget" Global Config
Setting core.autocrlf to true is the standard move for Windows users. This configuration acts like a bridge. It converts LF to CRLF when you pull code (checkout) and flips it back to LF when you push code (commit). Your repository stays clean, and your Windows tools stay happy.
# Apply this globally to your user account
git config --global core.autocrlf true
2. The Pro Way: Using .gitattributes
Individual global settings are hard to enforce across a team. If one teammate has a different config, you'll end up with a mess of mixed line endings. To prevent this, create a .gitattributes file at the root of your project. This file overrides local settings and forces the same rules for every contributor.
Create the file and add these rules:
# Treat all files as text and handle endings automatically
* text=auto
# Ensure shell scripts always use LF (Windows CRLF breaks bash scripts)
*.sh text eol=lf
# Ensure batch files always use CRLF
*.bat text eol=crlf
Commit this file to your repo. Now, whether a developer is on a Mac or a PC, Git will follow these exact rules.
3. Silencing the Warning
Maybe you don't want Git touching your files at all. If you are certain your code editors (like VS Code or Notepad++) handle LF perfectly fine, you can turn the conversion and the safety checks off.
git config --global core.autocrlf false
git config --global core.safecrlf false
Fixing Files Already in Your Repo
Changing your settings won't magically fix files you already committed with the wrong endings. You need to "renormalize" them. This process involves clearing the Git index and letting Git re-read every file using your new rules.
- Commit or stash any current work so your directory is clean.
- Run these three commands in order:
# 1. Clear the cached index
git rm --cached -r .
# 2. Re-add everything (Git applies new line-ending rules now)
git add .
# 3. Finalize the fix
git commit -m "Style: Normalize all line endings to LF"
How to Verify the Change
Check your current active setting by running:
git config --get core.autocrlf
If you use VS Code, look at the bottom right corner of the status bar. It will display CRLF or LF for the file you are currently editing. After running the normalization steps above, a file that previously showed LF should now show CRLF on your Windows machine, provided autocrlf is set to true.
Quick Comparison Table
Setting
On Commit
On Checkout
Best For
`true`
Converts to LF
Converts to CRLF
Windows users
`input`
Converts to LF
No change
Mac/Linux users
`false`
No change
No change
Windows-only teams