Git core.autocrlf Setting Causing Unwanted File Changes in PRs

A pull request showing every single line of a file as changed, when you know your actual edit only touched a few lines, is a strong signal that core.autocrlf silently converted the entire file's line endings during checkout or commit — the diff tool is technically correct that every line differs at the byte level, even though the visible content is identical, because the invisible line-ending character changed throughout the whole file.

The Problem

A pull request or diff shows a massive number of changed lines in a file, far more than the actual, intentional edit:

git diff --stat
 config.js | 145 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+), 72 deletions(-)

Reviewing the actual diff shows every line marked as both removed and re-added, even though visually the content looks completely unchanged — the giveaway that this is a line-ending issue rather than genuine content changes.

Why It Happens

core.autocrlf controls whether Git automatically converts line endings between LF (used internally in Git's own object storage) and CRLF (the Windows convention) during checkout and commit. When this setting differs between different contributors (one person has it set to true, converting to CRLF locally, while another has it set to input or unset, keeping LF), a file can end up with different line endings depending on who last touched it locally — and when that file is subsequently committed, Git sees every line as different at the byte level, because the underlying line-ending character genuinely did change throughout the file, even though the actual visible text content is unchanged.

The Fix

The most reliable, permanent fix is a .gitattributes file that explicitly and consistently defines line-ending behavior for your repository, overriding any individual contributor's personal core.autocrlf setting for files in this specific repository:

# .gitattributes
* text=auto eol=lf

This tells Git to normalize all text files to LF line endings in the repository itself, and to check them out with LF as well, regardless of what any individual contributor's own core.autocrlf setting might otherwise do — this single, repository-level source of truth eliminates the inconsistency that causes this exact PR-noise problem.

After adding or updating .gitattributes, existing already-committed files need to be explicitly renormalized to actually apply the new rule to their currently-stored content, since .gitattributes alone only affects future checkouts and commits, not retroactively fixing files already in the repository's history:

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

This produces a one-time commit that fixes any files with currently inconsistent line endings — after this, with .gitattributes properly enforcing consistency going forward, future commits shouldn't reintroduce the same problem regardless of any individual contributor's local Git configuration.

For a pull request that's already open and showing this noise before you've had a chance to fix the underlying repository-level configuration, you can locally correct the specific file's line endings before committing, as an immediate, targeted fix for that one file:

dos2unix config.js
git add config.js
git commit -m "Fix line endings"

This addresses the immediate symptom for that specific file, but doesn't prevent the same issue recurring for other files or future edits — the .gitattributes approach is the actual, durable fix, and this per-file correction should be treated as a stopgap specifically for an already-open PR you need to clean up before the broader fix is fully in place.

If your team includes both Windows and Unix-based (macOS/Linux) contributors, communicate the .gitattributes-based standard clearly, since it removes the need for each individual contributor to correctly configure their own personal core.autocrlf setting — the repository-level enforcement means this is no longer something each person needs to remember or get right individually, which is precisely what prevents this class of issue from depending on everyone consistently configuring their own environment correctly.

Still Not Working?

If you've added .gitattributes and renormalized, but a specific file continues to show this issue on every subsequent edit from a particular contributor, check whether that contributor's editor itself is configured to save files with CRLF line endings by default — .gitattributes controls what Git does with line endings during commit/checkout, but doesn't control what a text editor does when a file is actively being edited and saved locally; if the editor itself keeps introducing CRLF before the file is even committed, Git's own normalization on commit should still catch and correct it given a properly configured eol=lf rule, but confirming the editor's own line-ending setting removes one more potential source of confusion when troubleshooting a persistent, contributor-specific recurrence of this issue.