Configure Git Line Endings on Windows and Stop LF CRLF Warnings

If you work on Windows, you have probably seen a Git warning that says LF will be replaced by CRLF, or CRLF will be replaced by LF. It appears when you add files, commit changes, or clone a project. At first it looks scary, but it is not an error that breaks your code.

The warning is about how lines end in a text file. Different operating systems handle line endings in different ways. Once you understand that difference and set one clear rule in Git, the warnings stop and your team can work without confusion.

Quick Answer

On Windows, run git config --global core.autocrlf true to let Git convert LF to CRLF when you check out files and convert CRLF back to LF when you commit. For team projects, add a .gitattributes file with * text=auto so every computer follows the same rule. This combination stops most LF and CRLF warnings and keeps files consistent.

What Are LF and CRLF?

Every time you press Enter, your editor adds hidden characters at the end of the line. You cannot see them, but tools like Git can. The type of character depends on the operating system.

LF stands for Line Feed. It is a single character, written as \n. Linux and macOS use LF for line endings. Most servers, coding tools, and open source projects also expect LF.

CRLF stands for Carriage Return plus Line Feed, written as \r\n. Windows traditionally uses CRLF, so many Windows editors save files with CRLF by default.

When a file moves between Windows and Linux, Git notices the difference. If Git is not sure which format you want, it warns you. The warning is Git trying to protect you from mixing formats in the same project, which can cause large, messy diffs where every line looks changed even though the text is the same.

Why These Warnings Appear on Windows

The main reason is a mismatch between your editor, your operating system, and your Git settings. For example, you might clone a project created on Linux. Its files use LF. When you open and save them in a Windows editor, the editor may rewrite them with CRLF. Git then sees every line as changed.

This becomes a problem in teams. Code reviews become hard to read, and Linux shell scripts can fail if they receive CRLF.

How Git Handles Line Endings

Git has a setting called core.autocrlf. It controls conversion between LF and CRLF. There are three main values you need to know.

The Three core.autocrlf Settings

• true: Best for most Windows users. Git converts CRLF to LF when you commit, and converts LF to CRLF when you check out files on Windows.
• input: Best for Linux and macOS users, and for Windows users who use Linux tools like WSL. Git converts CRLF to LF when you commit, but does not convert on checkout.
• false: Git does no conversion at all. Files are stored and checked out exactly as they are. This is only safe if your whole team controls line endings in the editor.

You can read the full technical details in the official Git configuration documentation for core.autocrlf. It explains how Git decides when to convert a file and when to leave binary files alone.

Step-by-Step: Configure Git Line Endings on Windows

Follow these steps once on your computer. The setting is global, so it will apply to all your Git projects unless a project overrides it with its own rules.

1. Open Git Bash, PowerShell, or Windows Terminal in any folder.
2. Check your current setting by running git config --global core.autocrlf. If nothing appears, the setting has not been chosen yet.
3. Set the recommended Windows value by running git config --global core.autocrlf true.
4. Verify the change by running the first command again. You should now see true as the result.
5. Optionally, set a safe default for handling warnings with git config --global core.safecrlf warn while you learn, so Git warns before making an irreversible conversion.
6. Close and reopen your terminal and editor so they pick up the new setting.

If you are still learning the basics, our guide on how to install Git on Windows 11 step by step walks you through the first setup, including the installer option that also asks about line endings.

What If You Use WSL or Linux Tools on Windows?

If you edit code inside Windows Subsystem for Linux, treat your environment like Linux. In that case, input is often the better choice. It prevents Git inside WSL from creating CRLF files that Linux scripts cannot run.

Use .gitattributes for Team Projects

A global setting only controls your computer. Teammates may have different settings. The best way to make everyone follow the same rule is to add a .gitattributes file to the root of your repository. Git reads this file before it reads personal settings for line ending rules.

1. Create a new file named .gitattributes in the main folder of your project.
2. Add the line * text=auto as the first rule. This tells Git to handle text files automatically and store them with LF.
3. For specific file types, add clearer rules if needed, such as *.sh text eol=lf for shell scripts and *.bat text eol=crlf for Windows batch files.
4. Save the file, then run git add .gitattributes and commit it like any other file.
5. Ask your teammates to pull the change so the same rules apply on their machines.

Once this file is committed, you do not need to worry as much about each person’s global setting. The project itself carries the rule, which is much more reliable for long-term work.

Renormalize Files After Adding .gitattributes

If your project already has mixed line endings, adding the file alone may not fix old files. You need to renormalize them once.

1. Save and commit any work you do not want to lose.
2. Run git add --renormalize . to re-check all files under the new rules.
3. Review the changes with git status and commit them with a clear message like “Normalize line endings”.

This creates one larger commit, but after that, future diffs will be clean and small again.

Configure Your Editor as Well

Git is only half of the story. Your editor can also save files with the wrong endings. In Visual Studio Code, you can set the default by adding "files.eol": "\n" to your settings, which forces LF. You can also see the current format in the bottom status bar, where it shows LF or CRLF, and click it to change a single file.

Other editors like Notepad++, Sublime Text, and JetBrains IDEs have similar options. Look for a line ending or line separator setting and set it to Unix or LF for most programming projects. Only keep CRLF for files that are truly Windows-only, such as some PowerShell or batch projects where your team has agreed on CRLF.

Common Mistakes to Avoid

• Setting autocrlf to false on Windows without a plan: This stops warnings by stopping all conversion, but it lets CRLF files enter the repository and causes bigger problems for Linux teammates.
• Changing the setting but not renormalizing: Old files keep their old endings until you renormalize and commit them once.
• Editing the same project in Windows and WSL: Two Git installations with different settings fighting over the same folder will keep recreating warnings.
• Forcing conversion on binary files: Images, PDFs, and compiled files should never be treated as text. The * text=auto rule handles this, but do not add a rule that forces every file as text without care.
• Ignoring the editor: Fixing Git while your editor keeps saving CRLF for a Linux project will bring the problem back with every save.
• Committing a huge renormalization with code changes: Keep the line ending fix in its own commit so reviewers can understand what happened.

Conclusion

LF and CRLF warnings on Windows are not a sign that Git is broken. They are a sign that Windows and Linux handle text differently, and Git is trying to keep your repository clean. The fix is simple when you do it in the right order.

Set core.autocrlf to true on Windows, add a .gitattributes file with * text=auto to team projects, and set your editor to save with LF for most code. Then renormalize old projects once if needed. After that, warnings should disappear, diffs will be easy to read, and your files will work the same for everyone on your team.

Frequently Asked Questions

Should I choose true or input for core.autocrlf on Windows?

Choose true if you mainly work in Windows editors and Windows tools. Choose input if you work inside WSL or you want your working files to stay LF even on Windows. Most beginners on Windows should start with true.

Will changing line endings break my code?

For most programming languages, no. Python, JavaScript, HTML, and CSS work fine with LF. The main risk is with shell scripts, which must use LF to run on Linux, and with very old Windows tools that expect CRLF.

Do I need both a global setting and .gitattributes?

For solo projects, the global setting is usually enough. For team projects, yes, use both. The .gitattributes file makes the rule part of the project, so it does not depend on each person’s personal setup.

Why do I still see warnings after changing the setting?

Old files in the repository may still have mixed endings. Run git add --renormalize ., review the changes, and commit them. Also check that your editor is not saving files in the opposite format.

Can I turn off the warning without fixing line endings?

You can hide warnings by setting core.autocrlf to false, but that does not fix the underlying mix of formats. It is better to normalize the project properly so future diffs and scripts stay clean and predictable.