.gitattributes Tester

Because binary says it. It is not an attribute git looks up; it is a macro built into git that expands to -diff -merge -text, so one word on one line turns off diffs, turns off merging and turns off line-ending normalisation at once. Searching your .gitattributes for diff will not find it. The expansion happens exactly where the macro sits in the file, at that line's priority — which is why *.png binary followed by *.png diff=exif gives you the exif driver, while the same two lines in the opposite order give you diff: unset. This tester labels every state that arrived through a macro with the chain it came through, and flags the pair when a macro and an explicit line disagree about the same attribute.

The later one, every time, and that catches people out because so many config formats are first-match-wins. Inside one file the last matching line decides; if one line writes the same attribute twice, the state furthest to the right decides, so -text text leaves text set. Across files, the .gitattributes closest to the file wins over the one above it: a root * -diff is undone for everything under src/ by a single *.js diff=javascript in src/.gitattributes. Git also reads .git/info/attributes above all of them and core.attributesFile below them, neither of which lives in the repository, so neither is modelled here — if a resolved value surprises you and no line in your files explains it, those two are the places to look next.

-attr sets the attribute to unset — a definite answer, and for something like text it means "never normalise this file". !attr says the opposite kind of thing: it makes the attribute unspecified, as though no rule had mentioned it at all. The important part is that it still occupies the slot. Once a matching !text has been read, every lower-priority rule — earlier lines in the same file, and every parent .gitattributes — stops being able to fill text in. That makes it the tool for carving one subtree out of a repository-wide default, and it is also why git check-attr --all shows nothing for that attribute: --all prints only attributes that ended up with a value, so an !attr is invisible unless you ask for the name explicitly.

Almost. The matcher is the same one, so a pattern with no slash matches a bare filename at any depth below the file that holds it, a pattern with a slash anywhere is anchored to that file's directory, a leading / anchors it too, * and ? and [abc] stop at a separator, and ** is the only thing that crosses one. Two differences matter. A leading ! is not a negation here: git refuses the line outright, prints a warning and drops it, so you need \! for a filename that really starts with an exclamation mark. And a trailing slash, which in .gitignore restricts a rule to directories, is close to useless in .gitattributes — attributes are looked up per file, never inherited from a directory entry, so logs/ text gives an attribute to something git will not ask about.

Because those two attributes are applied when content moves between the repository and your working tree, not when the file sits there. Files already checked out keep the endings they have, and files already staged keep the endings that were stored. The fix after editing the rules is git add --renormalize ., which re-runs the conversion over every tracked file and stages whatever actually changed; expect a large, boring commit the first time. text=auto only converts files git decides are text by looking for NUL bytes near the start, so a UTF-16 source file is treated as binary and left alone unless you mark it text working-tree-encoding=UTF-16. And eol does nothing at all while text is unset, which is the usual reason a lone eol=lf line has no effect.

Only in the top-level .gitattributes at the root of the working tree, or in .git/info/attributes. Anywhere else git prints [attr]name ... not allowed and drops the definition — but the file still parses, so a line using that name keeps working as an ordinary custom attribute and nothing looks broken. Two more rules trip people up. A macro is expanded only where it is set: -mybin and mybin=maybe record a state for the name itself and expand nothing, so they do not undo the macro. And the definition may appear anywhere in the top-level file, including after the lines that use it, because macros are collected before any path is resolved.