In Git, what does marking a path binary in .gitattributes actually change?

## A macro, not a mode Git ships one built-in macro attribute, `binary`, defined as `-diff -merge -text`. Writing `*.pdf binary` in `.gitattributes` is exactly equivalent to writing the three unset attributes yourself. Knowing that expansion is the whole question, because each of the three does something separate and you sometimes want only one of them. ## Unsetting diff With `diff` unset, Git does not produce a textual diff for the path. `git diff`, `git show` and `git log -p` print a one-line notice that the files differ. This keeps review output readable when the content is machine-generated or genuinely non-textual, and it avoids the pathological case of a diff that is larger than the file. It is the attribute you want on its own when a file is textual but not worth reviewing line by line, such as a lockfile or a bundled artifact. `path -diff` gives you that without touching merge behaviour. ## Unsetting merge With `merge` unset, Git does not attempt a content-level three-way merge. When the two sides both changed the file, Git takes the version from the current branch as the tentative result and declares a conflict. Nothing is spliced, no conflict markers are inserted into the bytes, and the resolution is necessarily a whole-file choice: inspect both sides, pick one with `git checkout --ours <path>` or `git checkout --theirs <path>`, or regenerate the file, then `git add` it. This is the behaviour you want for anything where interleaving two edits produces a corrupt file: images, archives, compiled assets, and also plenty of text formats where a merged result would be syntactically valid but semantically wrong. ## Unsetting text With `text` unset, Git performs no end-of-line conversion in either direction, so the bytes stored and the bytes checked out are identical. For real binary content this is not optional; a conversion would corrupt the file. ## Why declare it when Git already guesses Git applies a content heuristic: if a blob contains a NUL byte near the start it is treated as binary for diff purposes. The heuristic is good but it is a guess made per blob, and it does not help for content that is textual by encoding yet must not be merged. Declaring the attribute gives you three things the heuristic cannot: it is explicit, so a reader of the repository sees the intent; it is committed, so every contributor and every automated checkout behaves the same way; and it covers merge and eol decisions, not only display. ## Choosing the right subset - Genuinely binary content: `binary` is right, all three unsets apply. - Generated text you do not want in review but do want merged as text: `-diff` alone. - Text you want reviewable but never auto-merged: `-merge` alone. - Reaching for `binary` on ordinary source files is a mistake that makes the file unreviewable and turns every concurrent edit into a manual conflict. ## Verifying and its limits `git check-attr -a -- path` shows the expanded result, so you can confirm the macro took effect. Two limits are worth remembering. First, attributes change how operations behave from now on; blobs already stored are unaffected until content passes through Git again. Second, marking a file binary does nothing about its *size*: large assets still bloat clones, and the attribute is a diff and merge decision, not a storage one.