In Git, why does `* text=auto` in .gitattributes beat asking everyone to set core.autocrlf?

## The two ways to state the rule Git converts line endings at check-in and checkout, and there are two mechanisms that decide whether it does. `core.autocrlf` (and its companion `core.eol`) are **configuration**: they live in `/etc/gitconfig`, `~/.gitconfig` or `.git/config`. `.gitattributes` entries are **content**: the file sits in the working tree, is tracked, and is committed and cloned like any source file. That difference is the whole answer, and it splits into four concrete advantages. ## 1. It travels A clone carries `.gitattributes` with it. The moment anyone clones the repository — a new hire, a fork, a CI runner, a Docker build, a release job — the rule is in effect without a setup step. Configuration carries none of that: it must be applied on every machine that will ever touch the repository, forever, and there is no way to detect from inside a clone whether somebody did. Line-ending churn is exactly the kind of defect that appears months later, from the one environment nobody configured. ## 2. It is one decision, not N decisions With per-machine config, the correct value differs by platform (`true` on Windows, `input` on Unix), so the team's policy is really "everyone must set the right one for their own OS". Set `true` on Linux and you fill the working tree with carriage returns. With `* text=auto` the repository states one platform-independent fact — *text blobs are stored with LF* — and Git derives the platform-appropriate working-tree form from `core.eol` or an explicit `eol` attribute. ## 3. It is per-path `core.autocrlf` is a single switch over the whole tree, backed by a content heuristic that guesses which files are text. Attributes let you be explicit where it matters, in one committed file: - `* text=auto` — detect text, store it as LF. - `*.sh text eol=lf` — always LF on disk, even on Windows, so shebang lines work. - `*.bat text eol=crlf` — always CRLF on disk, even on Linux, for tools that require it. - `*.png binary` — never touch it (the `binary` macro unsets `text`, `diff` and `merge`). - `*.snap -text` — a golden-file fixture whose bytes must not change. No configuration key can express "LF for scripts, CRLF for batch files, hands off the fixtures". ## 4. It wins Where both mechanisms cover a path, the attribute decides. That means the repository's committed policy is not at the mercy of somebody's inherited global config, and you can reason about the stored bytes from the repository content alone. `git check-attr text eol -- path` prints the effective attributes for a path, and `git ls-files --eol` shows what actually landed, so the policy is inspectable rather than assumed. ## What `text=auto` actually means `text=auto` asks Git to apply its text/binary heuristic per file: if the content looks like text, normalise it to LF in the object database and convert on checkout according to `eol`/`core.eol`; if it looks binary, leave it alone. Contrast plain `text`, which asserts the path *is* text and normalises unconditionally — dangerous applied globally with `*`, because a mis-classified binary would be corrupted. `auto` is the safe global default; explicit `text` or `binary` is the right tool for a specific path you know about. ## What the attributes file does not do by itself Adding `.gitattributes` changes the rule going forward; it does not rewrite blobs already committed. A repository with CRLF already in history keeps showing churn until you normalise it once with `git add --renormalize .` and commit the result. Nor do attributes stop a developer from committing a file whose *content* has mixed endings inside it — `core.safecrlf` at `warn` is the signal for that case. One more limitation worth naming: `.gitattributes` binds Git, not editors. It guarantees consistent blobs and consistent checkouts, but if an editor insists on rewriting a file, Git will convert it back on the way in — which is exactly the point: the noise stops at the repository boundary. ## Interview framing Lead with "config is per-machine and opt-in, attributes are committed and travel", then add the per-path expressiveness and the precedence rule, and mention that an existing repository needs one renormalisation pass before the policy is actually true of the stored blobs.