Rules / Format and vendor rules

mixed-eol

File mixes CRLF, LF or CR line endings.

note by default Format and vendor rules Inline suppression allowed

Source: git docs: gitattributes (git-scm.com), read 14 October 2026.

On GitHub: the rule doc and the tests.

All rules73

What it catches#

File mixes CRLF, LF or CR line endings.

A file that uses more than one line ending: some lines end in CRLF, others in LF (or bare CR). The message gives the counts. It is a note: agents read the file fine. The problem is the next edit.

Why it matters#

Mixed endings are easy to normalise by accident in an edit, which turns a small change into a whole-file diff.

Bad example#

$ file CLAUDE.md
CLAUDE.md: Unicode text, UTF-8 text, with CRLF, LF line terminators

One contributor on Windows pasted a section into a file that was LF. The next editor or formatter that normalises line endings turns a one-line change into a diff that touches every line, which hides the real change in review.

Good example#

$ file CLAUDE.md
CLAUDE.md: Unicode text, UTF-8 text

How to fix#

Pick one ending for the repository. Add * text=auto eol=lf to .gitattributes, run git add --renormalize . and commit. Until then, edit minimal ranges so the existing endings stay as they are.

Suppress or configure#

For one finding, put a comment on the line above it. The reason after -- is optional but worth writing:

<!-- asitis-disable-next-line mixed-eol -- why this one is fine -->

For a whole file:

<!-- asitis-disable-file mixed-eol -- why this file is an exception -->

For every file, turn it off or change its severity in .asitisrc.json:

{ "rules": { "mixed-eol": "off" } }

A .asitisrc.json overrides entry limits a change to some paths, and a baseline (asitis lint --format json --write-baseline) accepts today's findings so only new ones fail the build.

Source#

git docs: gitattributes, read on 14 October 2026.

This page is generated from the plugin's rule registry. Edit it on GitHub. False positive? Open an issue with the line it fired on.