If Git suddenly marks nearly every file as modified on your Mac, line ending conversion may be making the working copy differ from the version Git tracks. First inspect the repository before changing or restoring files. Then use macOS-appropriate Git settings, and only renormalize after protecting any real edits. Git recommends storing text with LF endings; its macOS guidance uses core.autocrlf input. GitHub’s line-ending guide

Why can line endings make every file look changed?

A line ending marks the end of each line: Unix-style LF uses one character, while Windows-style CRLF uses a carriage return plus a line feed. If Git or an editor changes endings throughout a working copy, Git may report broad file changes even when the text itself looks the same. Git can normalize text to LF in its index and apply different endings when checking files out, depending on configuration and .gitattributes. Git’s gitattributes documentation

Inspect the repository before fixing it

Open Terminal, move into the repository, and check its status and line-ending settings:

git status --short
git config --show-origin --get core.autocrlf
git ls-files --eol

The config command may print nothing if no value is set. --show-origin helps identify which config file supplied the setting. In git ls-files --eol, compare the index (i/) and working-tree (w/) endings; mixed signals mixed endings. The attr/ value shows applicable attributes. Git documents this output as a diagnostic of the index, working tree, and line-ending attributes. Git’s git-ls-files documentation

Also check for actual edits before proceeding. If you find changes you want, commit them or copy them somewhere safe. Do not use a blanket restore or reset as a line-ending fix: those commands can discard work. Binary files need particular care because line-ending conversion can damage data if Git treats them as text. Git’s git-config documentation

Set a sensible default for macOS

For your own Git use across repositories, set the documented macOS preference:

git config --global core.autocrlf input

With input, Git normalizes CRLF to LF when adding text, without converting LF files to CRLF on checkout. This setting does not settle every file’s policy: repository attributes can specify behavior by file type, and Git’s text and eol attributes control normalization and checkout endings. GitHub’s platform-specific guidance and Git’s configuration reference

If the problem is limited to one project, prefer that project’s .gitattributes policy over changing your global configuration to suit one repository. A common starting point is * text=auto; specific formats can be pinned to LF or CRLF, while binary formats should be marked binary. For example, shell scripts commonly need LF, while some Windows project files require CRLF. The correct patterns depend on the repository’s tools and collaborators. Git’s gitattributes examples

* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

Renormalize only after reviewing the changes

Changing configuration or attributes does not guarantee that existing files immediately become consistent. GitHub’s documented refresh procedure first saves or commits outstanding work, then runs git add --renormalize . and reviews the resulting status. GitHub’s refresh instructions

After you have safely saved your edits and settled the repository policy, stage normalization and inspect exactly what Git proposes:

git add --renormalize .
git status --short
git diff --cached --stat
git diff --cached

Do not commit automatically. Review the staged diff, especially unexpected binary or generated files. If it still shows content changes you did not intend, stop and inspect the affected paths and their attr/ values with git ls-files --eol; correct the attribute policy before staging again. Renormalization can produce a large legitimate diff if the repository previously stored inconsistent endings, so coordinate a normalization commit with collaborators when needed.

If the files remain modified

Line endings are only one possible cause. Look for substantive differences in the staged or unstaged diffs, check whether an editor rewrote files, and inspect file-specific filters or attributes. If git ls-files --eol reports i/lf and w/crlf, confirm whether an attribute or setting intentionally requests CRLF. If it reports mixed, identify which files have mixed endings and whether they are text before normalizing. Git’s safety checks can warn about irreversible conversions, but they cannot tell whether a file was incorrectly classified as text. Git’s configuration reference

The practical sequence is: protect edits, inspect core.autocrlf and git ls-files --eol, choose a consistent project policy, then renormalize and review the diff. This addresses line-ending noise while leaving you in control of any real content changes.

Sources