Git, Still Using autocrlf in 2025? That's Frustrating

Sometimes I still see company repositories relying on core.autocrlf. Honestly, using this in 2025 feels frustrating.

Line ending issues used to be a real headache. Windows used CRLF, Linux and macOS used LF. When developers on different operating systems touched the same code, even minor changes caused massive diffs, and scripts would fail with ^M errors. Git's answer was autocrlf, which tried to "fix line endings automatically in your local Git config." At first it looked convenient, but over time it created more confusion than it solved. With each developer using different settings, one person worked with CRLF, another with LF, and the same repository behaved differently across machines. The so‑called "line ending war" never really ended.

Git Was Always Awkward in Companies

Git was originally built for open source collaboration. In an environment like the Linux kernel, with thousands of contributors sending patches, it excelled. But companies are different. A company defines a standard platform and tooling, and dozens of developers are expected to work under a single rule set. In that context, Git's philosophy—"individual freedom, distributed choice"—often feels awkward. Line endings are a perfect example: where a team rule is needed, Git pushed the responsibility to individual developers.

Yes, things have improved. Windows support is much better now, IDE integration is smooth. Still, when you use Git in a company, there remain these annoying pain points. Line endings are one of them.

These Days, CRLF or LF Doesn't Matter Much

Let's be honest. Visual Studio, VS Code, IntelliJ, Rider, Xcode, even Notepad all handle both CRLF and LF just fine. Regardless of how a file is saved, modern IDEs can open and re‑save without issues. For most code files, whether they use CRLF or LF barely matters anymore. The desperate need to "force everything to one style" is mostly gone.

So why do we still talk about line endings? Because some files really do need a specific line ending.

Some Files Must Be Enforced

Windows batch files (.bat, .cmd), PowerShell scripts (.ps1), and Visual Studio solution/project files (.sln, .csproj, .vcxproj) can break or misbehave without CRLF. On the other hand, shell scripts (.sh) and Dockerfiles fail if they're not LF.

That's where .gitattributes comes in. By committing this file into the repository, Git enforces line ending rules consistently, regardless of personal settings. In other words, a team's agreement is encoded in the codebase itself.

Example: Windows‑Centric Teams

If your company is Windows‑centric, your .gitattributes might look like this:

# Default to CRLF
* text=auto eol=crlf

# Files executed in Linux/Unix environments must be LF
*.sh       text eol=lf
Dockerfile text eol=lf

# Windows‑specific files must use CRLF
*.bat     text eol=crlf
*.cmd     text eol=crlf
*.ps1     text eol=crlf
*.sln     text eol=crlf
*.vcxproj text eol=crlf
*.csproj  text eol=crlf

# Never convert binaries
*.png -text
*.jpg -text
*.gif -text
*.pdf -text
*.zip -text

This way only the necessary files have enforced line endings, and everything else can be left to the IDE. There's no need for overkill like "normalize all text to LF."

Why autocrlf Should Be Off

There's simply no reason to keep autocrlf enabled. It rewrites files locally, and that's often the root of the problem. With .gitattributes in place, Git prioritizes the repository rules anyway, so local settings are useless or even harmful.

For teams, the most stable setup is core.autocrlf=false. Let the repository handle line endings, and let Git keep files "as is." If you're worried about accidental changes, enable core.safecrlf=true to block unsafe conversions.

git config --global core.autocrlf false
git config --global core.safecrlf true

Conclusion

Line ending issues are no longer something IDEs fail to solve. IDEs already support both CRLF and LF seamlessly. What matters is that some files still require a specific line ending, and the only reliable way to enforce this is through .gitattributes, not personal Git configs.

So turn off autocrlf. Forget the obsession with "normalize everything to LF." Modern IDEs handle both. The only thing that matters is this: if a file requires a specific line ending, enforce it explicitly with .gitattributes.

Do this, and the line ending wars finally end. No more pointless diffs, no more blame pollution, no more frustration.