git check-attr

Why is this file being treated like text? This tells you.

🎯 What & why

Tells you which .gitattributes rules apply to a given path. The answer to 'why is git treating this file as text/binary/whatever?'.

🧠 Mental model

Think of it as a query tool against the attribute resolution engine. Same precedence as the actual checkout uses: per-directory .gitattributes, then $GIT_DIR/info/attributes, then global. check-attr just reports the result.

🛠️ Synopsis

git check-attr [-a | <attr>...] [--cached] [-z] [--stdin] [--] <pathname>...

Output format:
  <path>: <attr>: <value>
where <value> is set | unset | unspecified | <string>

🎚️ Switches & options

Flag	What it does
`-a, --all`	Show every attribute defined for the path. Don't pass attrs explicitly.
`--cached`	Use attributes from the index, not the working tree (matches what checkout/diff sees in CI).
`--stdin`	Read paths from stdin. Pair with -z for NUL-separated paths.
`-z`	NUL-separate input and output. Use whenever paths could contain newlines.
`<attr>...`	Specific attributes to query (e.g. text eol diff). Faster than -a.

💡 Use cases

Diagnosing line-ending mangling: 'check-attr text eol crlf README.md'.
Verifying that linguist-vendored hides node_modules from GitHub language stats.
Confirming a custom merge driver applies to .lock files.
Auditing CI behavior with --cached when the working tree differs from the index.

🧪 Examples

Show every attribute on a file

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

Check specific attributes

git check-attr text eol diff README.md

Bulk audit all tracked paths

git ls-files -z | git check-attr --stdin -z -a

What does CI see?

git check-attr --cached -a generated/output.bin

🎓 Recommendations

When debugging EOL issues, query 'text', 'eol', and 'crlf' together; the interaction is non-obvious.
Use --cached in CI investigations: working-tree edits to .gitattributes don't take effect until staged.
Pipe ls-files -z through check-attr --stdin -z for repo-wide audits; spaces in filenames will not bite you.

🪤 Common pitfalls

A bare 'unspecified' means no rule matched, which is different from 'unset'. Behavior then falls back to git defaults (often: auto-detect text vs binary).
check-attr reads .gitattributes from the working tree by default. If you've edited it but not staged, --cached will disagree.
Attribute precedence is closest-directory-wins, then info/attributes, then global. A surprising override often lives in a nested .gitattributes you forgot about.

🔗 Related modules

📝 Quiz

Hit each option, then Check answers. Score is recorded; Next is always open.