Introduction

If git status shows files as modified even though core.autocrlf=false, the cause is usually broader than line-ending conversion. autocrlf=false only tells Git not to rewrite line endings automatically on checkout and commit; it does not disable .gitattributes, editor changes, file-mode tracking, BOM changes, or clean and smudge filters.

Start by asking what actually changed

The first step is to inspect the diff rather than guessing:

git diff -- path/to/file

If the diff looks empty, compare with line-ending-insensitive output:

git diff --ignore-cr-at-eol -- path/to/file

If the file stops showing changes with --ignore-cr-at-eol, line endings are involved. If not, the issue is somewhere else.

autocrlf=false does not override .gitattributes

Many developers miss this. Repository-level attributes can still normalize line endings even when the local Git config disables autocrlf.

For example:

*.sh text eol=lf
*.bat text eol=crlf

In that repository, Git still has explicit end-of-line rules. So if your editor writes a file with the wrong convention, git status can show modifications even though core.autocrlf is false.

To inspect attributes:

git check-attr -a -- path/to/file

That command is often more revealing than staring at global config.

Other common causes besides line endings

Several non-EOL issues can make a file appear modified:

• executable bit changes on Unix-like systems
• UTF-8 BOM added or removed
• trailing whitespace stripped by the editor
• clean and smudge filters rewriting content
• generated files or formatters touching the file automatically

If the problem is file mode, check:

git config core.filemode

On some filesystems, setting:

git config core.filemode false

reduces noisy permission-only changes.

Check the editor and tools around Git

Editors often normalize files on save. A file can be "modified" without any visible text edit because the editor changed:

• line endings
• encoding
• BOM presence
• final newline
• whitespace indentation

That is why the issue can appear even in a repo with careful Git config. Git is just reporting that the bytes changed.

If only one editor produces the problem, inspect that editor's save settings before changing Git defaults across the whole machine.

Another useful check is to compare the file in the index against the working tree with a binary-aware tool. When the diff looks invisible in the terminal, encoding markers or whitespace normalization are often the missing explanation.

A practical diagnosis flow

A reliable troubleshooting sequence is:

1. run git diff -- path/to/file
2. run git diff --ignore-cr-at-eol -- path/to/file
3. run git check-attr -a -- path/to/file
4. inspect file mode, encoding, and editor save settings

That path usually reveals whether the problem is:

• EOL normalization
• repository attributes
• permission metadata
• editor or formatter behavior

It is much more effective than toggling autocrlf repeatedly.

Common Pitfalls

The biggest mistake is assuming core.autocrlf=false means "Git will never show text-format-related modifications." It only disables one conversion behavior.

Another mistake is ignoring .gitattributes. Repository rules often matter more than local Git config because they travel with the project.

Developers also overlook file-mode changes on Linux and macOS, especially when working on mounted or unusual filesystems.

Finally, do not reset files blindly before understanding the cause. If an editor or formatter is rewriting them automatically, the noise will come back immediately.

Summary

• 'core.autocrlf=false disables one Git conversion mechanism, not every source of file modification.'
• Use git diff and git diff --ignore-cr-at-eol to see whether line endings are really the issue.
• Check .gitattributes, because repository rules can still enforce EOL behavior.
• Inspect file mode, encoding, BOM, and editor save settings too.
• Diagnose the actual byte-level change instead of toggling Git config blindly.