Stop Git CRLF Warnings on Windows: Fix LF→CRLF

You're on Windows, you type git add on a file, and Git spits out that annoying warning: LF will be replaced by CRLF. It usually pops up on the first commit, right after a fresh clone or when you've edited a file that was checked out with Unix-style line endings. I've seen this in a client's repo last week—their devs were split between Mac and Windows, and every commit made the warning noise. It's harmless, but it's also a sign your line endings are a mess.

What's Actually Happening

Think of it like this: Windows text files end lines with two characters—carriage return and line feed (CRLF, \r\n). Unix and macOS use just a line feed (LF, \n). Git stores files in the repo with LF endings by default, because that's the lingua franca. But on Windows, when Git checks out a file, it converts LF to CRLF so your notepad and old tools don't break. When you stage a file, it converts back to LF. That conversion triggers the warning.

The root cause? Your core.autocrlf setting is probably set to true. That's fine for old-school Windows-only repos, but if you work with anyone on Linux or macOS, you'll get this warning on both sides. The real fix isn't tweaking that setting per machine—it's using a .gitattributes file to declare the rules for everyone.

The Fix, Step by Step

Here's what I do for every Windows client that hits this. It's clean, it's permanent, and it silences the warning for the whole team.

1. Check your current setting. Open Git Bash or PowerShell and run:
   

   git config core.autocrlf

   If it returns true, that's your culprit. If it returns nothing, you're on the default (which on Windows installers is often true).
2. Create or edit .gitattributes in the root of your repository. If it doesn't exist, create it. Use a decent editor—not Notepad, because that can mess up encoding. I like VS Code.
3. Add these lines to the file:
   

   # Auto detect text files and normalize to LF
   * text=auto
   
   # Explicitly set line endings for common file types
   *.js text eol=lf
   *.ts text eol=lf
   *.json text eol=lf
   *.md text eol=lf
   *.sh text eol=lf
   
   # Binary files should stay untouched
   *.png binary
   *.jpg binary
   *.pdf binary
   

   That first line tells Git to treat all text files as text and normalize them to LF. The per-extension lines force LF for files that should never have CRLF, especially on Windows. Adjust the extensions to match your project.
4. Commit the changes. But before you do, Git needs to re-normalize your working tree. Run:
   

   git add --renormalize .
   git commit -m "Normalize line endings"

   The --renormalize flag tells Git to apply the new rules to every file, converting CRLF to LF in the index. This is safer than deleting and re-checking out everything.
5. Set core.autocrlf to false on your machine:
   

   git config --global core.autocrlf false

   This stops Git from doing its own conversion on checkout. Now Git will just trust the .gitattributes rules. The warning should disappear because there's no conversion happening on the fly.

What If It Still Fails?

If you still see the warning after those steps, check a few things:

• Did you commit .gitattributes? If it's not tracked, it's not working. Run git status and make sure it's listed.
• Is your working tree clean? Sometimes old files with CRLF stick around. Do a hard reset after committing the normalization:

  git reset --hard

  That re-checks out everything with the new rules.
• Check for conflicting settings. If you have a .gitconfig in your home that sets something weird, it might override. Run git config --list and look for any core.eol or core.autocrlf entries.
• Verify with a test. Create a new file, add it, and see if the warning shows. If it does, your .gitattributes might not be picking up the extension—make sure the pattern matches exactly, like *.js not *.JS.

This approach works because it's not a band-aid. You're telling Git how to handle line endings for everyone, forever. I've fixed a dozen repos this way, and the warning stays gone. One last thing—if you're on a repo that already has mixed line endings in history, don't try to fix the history. It's not worth the headache. Just normalize going forward.