Fix line-ending problems that show every file as modified

Does this match your situation?

• git status shows files as modified with no visible change.
• git diff shows every single line as changed.
• 'warning: LF will be replaced by CRLF' on every add.
• Shell scripts fail with 'bad interpreter' or '\r: command not found'.

Step-by-step fix

1. Confirm line endings are the cause

   If the diff disappears when whitespace is ignored, the change is invisible characters rather than real edits.

   step 1Copy

   git diff | cat -A | head -20      # ^M at line ends means CRLF
   git diff --ignore-all-space         # empty? then it is purely line endings
   

   Show the PowerShell (Windows) version

   PowerShell (Windows)Copy

   git diff --ignore-all-space
   git config core.autocrlf
   

2. Add a .gitattributes policy

   Because .gitattributes is committed, it applies identically for everyone who clones — which is exactly why it beats core.autocrlf, a per-machine setting that different teammates inevitably have set differently.

   step 2Copy

   # .gitattributes
   * text=auto
   
   *.sh   text eol=lf
   *.bash text eol=lf
   *.bat  text eol=crlf
   *.cmd  text eol=crlf
   *.ps1  text eol=crlf
   
   *.png binary
   *.jpg binary
   *.fbx binary
   *.wav binary
   

   ✅text=auto stores LF in the repository and checks out whatever is native to each machine. eol= pins files that must have a specific ending regardless of platform.

3. Renormalise everything already committed

   The new rules only affect future writes until you rewrite the existing entries. This produces one large commit that touches many files and is best done when nobody has work in flight.

   step 3Copy

   git add .gitattributes
   git commit -m "Add line-ending policy"
   
   git add --renormalize .
   git status
   git commit -m "Renormalise line endings across the repository"
   

4. Set a sensible local default too

   A belt-and-braces default for repositories that have no .gitattributes of their own.

   step 4Copy

   # Windows
   git config --global core.autocrlf true
   
   # macOS / Linux
   git config --global core.autocrlf input
   

   💡Never use core.autocrlf true on macOS or Linux - it writes CRLF into files that should have LF.

5. Refresh your working copy

   After renormalising, re-check out the tree so every file on disk matches the new policy.

   step 5Copy

   git rm --cached -r .
   git reset --hard
   

Why this works

Git stores file contents byte for byte, so a carriage return is as much a change as a letter. Windows tools write CRLF and Unix tools write LF, which means the same logical edit produces different bytes on different machines and Git honestly reports every line as changed. `text=auto` resolves this by normalising to LF inside the repository and converting on checkout, so the stored form is consistent no matter who committed it. Putting the rule in .gitattributes rather than local config is what makes it a team-wide guarantee instead of a per-machine hope.

How to stop it happening again

• Add .gitattributes with `* text=auto` to every new repository on day one.
• Pin shell scripts to eol=lf and Windows batch files to eol=crlf.
• Configure your editor to respect .editorconfig alongside it.

Commands used in this guide

Frequently asked questions