The CRLF Disaster That Made Me Respect .editorconfig

Prettier Fatigue and a CRLF Disaster Recovery Log

reimagined with AI for this article (Original EditorConfig logo by Kat On)

One accidental CRLF commit turned our entire git blame history into noise.

Every line looked modified. Nobody could tell who changed what. Code review became painful, and tracking ownership became nearly impossible.

Ironically, the project already had an .editorconfig file.

It was there.

It was correct.

And it was completely ignored.

That incident made me rethink a simple question:

In the age of Prettier, ESLint Stylistic, and Biome — do we still need .editorconfig?

When .editorconfig Exists but Changes Nothing

Recently, a developer from another team I was collaborating with was managing a file with CRLF (Windows style) line endings, without realizing the project already had this rule defined. The problem was that every time I opened, edited, and saved that file, it was automatically converted to LF (Mac/Linux style) to match my environment, resulting in an awkward situation where every single line was marked as modified in Git.

I had to temporarily break my own local .editorconfig rules just to make the PR safe, then advise the developer in charge to batch-convert everything back to LF later.. However, they were extremely worried about losing the past code history (git blame) of the entire file.

The cause of this disaster was clear. There was definitely an .editorconfig with end_of_line = lf written in the project, but VS Code, the most widely used editor today, does not support it natively. Because their editor didn't have the 'EditorConfig' extension installed, this excellent convention was simply ignored as a 'meaningless text file'.

💡 Why Does VS Code Stubbornly Insist on Extensions? The VS Code open-source project issue tracker holds the long-standing desires of developers asking to include .editorconfig as a native spec. However, Microsoft rejected this, citing the need to maintain the extension ecosystem. — Issue #56742, Issue #95902

VS Code Project Team Convention Guide

Until the day VS Code adopts this convention as a true native standard, teams need to build their own guardrails.

① Utilizing .vscode/extensions.json (Required)

{
  "recommendations": [
    "editorconfig.editorconfig"
  ]
}

Force a mandatory extension installation pop-up to appear when a new hire or another team member opens the project for the first time. This is the most certain first line of defense.

② Final Defense with .gitattributes (Double Lock)

* text=auto eol=lf

Even if the editor settings are breached, you must put up a shield to force conversion to LF at the time of the Git commit. Add the following to your project root.

git config blame.ignoreRevsFile

git config blame.ignoreRevsFile — how it works (visualization by ChatGPT)

As my fellow developer worried, what should you do if CRLF commits are already merged into the main branch and git blame is a complete mess? At this time, using **.git-blame-ignore-revs introduced in Git 2.23**, you can gracefully restore the tracking without damaging the physical commit history at all.

1. Create a Normalization Commit:

Realign the line endings of all files in the terminal to create a normalization commit.

git add --renormalize .

2. Write the Ignore File:

Create a .git-blame-ignore-revs file in the root directory and write the hash values of the commits you want to treat as invisible in the history (the CRLF accident commit and your normalization commit).

z9y8x7w6v5u4t3s2r1q0...

3. Apply Configuration:

Share the following command for team members to run in their respective local environments.

git config blame.ignoreRevsFile .git-blame-ignore-revs

Wrapping Up

I still hope for the day when every editor and IDE treats [.editorconfig](https://editorconfig.org/) as a true native standard—not an optional extension.

Until then, teams need to build that discipline themselves.

Because one accidental CRLF commit is enough to remind you:

formatting is not about style.

It’s about trust.

.editorconfig is boring.

That’s exactly why it matters.