Why Git Shows the Whole File Changed After a One Line Edit

You open a file, fix one small line — maybe a single word or a missing comma — and save it. Then Git tells you the entire file has changed. Every line appears as deleted and added again, turning a tiny edit into a diff hundreds of lines long.

This problem confuses beginners and annoys experienced developers, because it makes code reviews messy and hides the real change. Reviewers cannot spot your one important line inside a wall of red and green.

Thankfully, the cause is usually simple and invisible: line endings. In this guide, you will learn why Git shows the whole file as changed, how to confirm the cause, and how to fix it for good on your computer and for your whole team.

Quick Answer

Git usually shows the whole file as changed because the line endings changed from LF to CRLF, or the other way around, so every line looks different even though the text is the same. Fix it by setting git config --global core.autocrlf correctly for your system, adding a .gitattributes file with * text=auto, and converting the file back to one consistent ending style.

What Are Line Endings, and Why Are They Invisible?

Every time you press Enter, your editor adds hidden characters to mark the end of the line. These characters are not printed on screen, but they are part of the file, just like letters and spaces.

Two styles exist. Windows traditionally uses CRLF — Carriage Return plus Line Feed, two characters. Linux and macOS use only LF, one character. The text looks identical either way.

Git, however, compares files byte by byte. If one version of a line ends with LF and the next version ends with CRLF, Git sees two different lines. Change the endings on every line, and Git honestly reports that every line changed.

This often happens when a file moves between systems and an editor rewrites all endings in the other style.

Other Causes Worth Knowing

Line endings are the most common cause, but not the only one. Keep these in mind if the main fix does not solve your case:

• Whitespace changes: Your editor may have replaced tabs with spaces, or trimmed spaces, across the whole file.
• A formatter ran on the whole file: Auto-formatters can rewrap lines and change spacing in every paragraph or function.

The checking steps below help you discover which cause applies, so you do not apply the wrong cure.

How to Confirm It Is a Line Ending Problem

1. Run git diff --stat to see how many lines Git thinks changed. A whole file listed for a one-line edit is the first clue.
2. Run git diff -w or git diff --ignore-all-space. If the huge diff shrinks to your real one-line change, whitespace or line endings are the cause.
3. Run git diff --word-diff to highlight changes word by word. If nothing meaningful appears, the bytes changed, not the words.
4. Check the file’s endings with a tool. On Linux or macOS, file filename may report CRLF line terminators. Many editors also show LF or CRLF in the status bar.

The -w test is the quickest detective step. It tells Git to ignore whitespace when comparing, and line ending differences count as whitespace for this purpose. A clean small result almost proves the diagnosis.

The official Git configuration documentation describes the line ending settings in detail for readers who want the full technical reference.

The Main Fix: Set core.autocrlf Correctly

Git has a setting that converts line endings automatically as files move between your working folder and the repository. Setting it correctly for your operating system prevents most problems.

On Windows

git config --global core.autocrlf true

With this setting, Git stores LF in the repository but gives you CRLF in your working files, which suits most Windows editors. Files are converted quietly in both directions.

On macOS and Linux

git config --global core.autocrlf input

This setting converts CRLF to LF when you commit, but does not change files when you check them out. It stops stray Windows endings from entering the repository from your machine.

If you are setting up Git for the first time, our guide on how to install and configure Git on Windows 11 covers this setting alongside the other essentials.

The Team Fix: Add a .gitattributes File

Personal settings help, but every teammate has their own machine and config. A project can protect itself by keeping the rule inside the repository, in a file called .gitattributes.

1. Create a file named .gitattributes in the root folder of your project.
2. Add this line: * text=auto eol=lf
3. Save the file and commit it like any other project file.
4. Ask teammates to pull the change so everyone shares the same rule.

This tells Git to treat text files consistently for everyone, no matter which system or editor each person uses. It is the single most effective long-term fix, and most professional projects include one.

You can add specific rules too, such as *.sh text eol=lf for shell scripts.

How to Fix a File That Already Has Mixed Endings

Settings prevent future problems, but a file that is already mixed needs a one-time cleanup. Follow this order so the cleanup itself does not create chaos:

1. Commit or stash your real work first, so the working folder is clean.
2. Make sure your core.autocrlf setting and .gitattributes file are in place.
3. Open the problem file in your editor and change its line ending setting to LF. Most editors, including VS Code, let you click the LF or CRLF label in the status bar to switch.
4. Save the file. Git may now show the whole file as changed one final time — this is the normalisation commit.
5. Commit it on its own with a clear message like Normalize line endings in filename, separate from real code changes.

The GitHub guide to configuring Git for line endings walks through these settings with examples for each operating system.

How to Review a Diff Without the Noise

Sometimes you cannot fix a messy file right away, but you still need to review the real change hiding inside it. These commands help:

• git diff -w ignores whitespace and ending changes, showing only real content edits.
• git diff --ignore-blank-lines hides changes that only add or remove empty lines.
• On GitHub, add ?w=1 to the end of a pull request diff page URL to ignore whitespace in the browser view.

These are viewing tools, not fixes. They help today, while the settings and .gitattributes file stop the problem from returning tomorrow.

Editor Settings That Prevent the Problem

A few one-time editor settings help a lot. In VS Code, set "files.eol": "\n" for LF by default, add an .editorconfig file with end_of_line = lf so every editor follows the same rule, and turn off unplanned trim or format-on-save options for shared projects. Before committing, glance at git diff --stat — hundreds of changed lines after a tiny edit is a warning to check endings first.

Common Mistakes to Avoid

• Committing the giant diff with real changes mixed in: This buries your actual edit and makes reviews and history painful for everyone. Fix endings in a separate commit.
• Setting autocrlf to false everywhere without a .gitattributes file: This removes protection completely, and mixed endings flow straight into the repository.
• Blaming Git and reinstalling it: Git is comparing bytes correctly. The file truly did change; the fix is settings, not reinstallation.
• Fixing endings on a binary file: Images and other binary files must never be treated as text. Mark them binary in .gitattributes if Git misdetects them.
• Normalising files without warning the team: A normalisation commit touches every line, so coordinate it to avoid conflicts with teammates’ open work.
• Ignoring the warning signs: If git diff --stat looks wrong for your edit, pause. One minute of checking saves an hour of messy history.

Conclusion

When Git shows your whole file as changed after a one-line edit, invisible line endings are almost always the reason. Windows CRLF and Unix LF look the same to you, but Git compares bytes and sees every line as new.

Confirm it with git diff -w, set core.autocrlf correctly for your system, and protect the project with a .gitattributes file. Do the one-time normalisation in its own commit, and your future diffs will show only the changes you really made — small, clear, and easy to review.

Frequently Asked Questions

What is the difference between LF and CRLF?

LF is a single character that ends a line on Linux and macOS systems. CRLF is a pair of two characters used traditionally on Windows. The visible text is identical, but the hidden bytes differ, and Git compares bytes.

Which autocrlf setting should I use?

Use true on Windows and input on macOS and Linux. This common pairing keeps the repository stored in LF while letting each system work comfortably with its own files.

Will changing line endings break my code?

For most languages, no. A few tools are strict: shell scripts need LF, and Windows batch files expect CRLF. The .gitattributes file lets you set exact rules for those special file types.

How can I see a file’s line endings quickly?

Most editors show LF or CRLF in the status bar when a file is open. On the terminal, the file command on Linux and macOS often reports CRLF line terminators when they are present.

Why did this start happening after a teammate joined?

Your teammate likely uses a different operating system or editor setting, so their saves rewrite endings across files they touch. Adding a shared .gitattributes and .editorconfig aligns everyone and stops the problem at its source.