GIT-CHECK-IGNORE(1)

πŸŽ€ git-check-ignore(1) πŸŽ€

okay bestie, welcome to the git-check-ignore page β€” it's the git manual's very own detective for gitignore / exclude files, and honestly? iconic. πŸ•΅οΈβ€β™€οΈβœ¨


✨ SYNOPSIS ✨

git check-ignore [<options>] <pathname>...
git check-ignore [<options>] --stdin

πŸ’– DESCRIPTION πŸ’–

so here's the vibe: for every single pathname you hand over β€” either straight on the command line, or from a file via --stdin β€” it checks whether that file is excluded by .gitignore (or whatever other input files feed into the exclude mechanism), and if it is excluded, it prints the path out. simple as that. πŸ’…

and by default, tracked files just… don't show up at all 🌸 β€” because they're not subject to exclude rules, periodt. but hey, see --no-index if you wanna change that story.


🌈 OPTIONS 🌈

  • -q, --quiet β€” don't output anything babes, just set the exit status. ⚠️ this one's only valid with a single pathname, no cap.
  • -v, --verbose β€” instead of printing just the paths that are excluded, for each path that matches an exclude pattern it prints the exclude pattern together with the path. (heads up: matching an exclude pattern usually means the path is excluded, but if the pattern begins with "!" then it's a negated pattern β€” and matching that means the path is NOT excluded. plot twist 😭)

for the precedence rules within and between exclude sources, go peek at gitignore(5).

  • --stdin β€” read pathnames from standard input, one per line, instead of from the command-line. v chill of it. 🫢
  • -z β€” modifies the output format to be machine-parsable (see below πŸ‘€). and if --stdin is also given, input paths get separated with a NUL character instead of a linefeed character.
  • -n, --non-matching β€” show given paths which don't match any pattern. ⚠️ this only makes sense when --verbose is enabled, otherwise you literally couldn't distinguish between paths that match a pattern and paths that don't. it's giving logic.
  • --no-index β€” don't look in the index when undertaking the checks. this is your debug bestie πŸ› for figuring out why a path became tracked by e.g. git add . and wasn't ignored by the rules the way you expected β€” or for when you're developing patterns (including negation) to match a path previously added with git add -f.

πŸ¦‹ OUTPUT πŸ¦‹

by default, any of the given pathnames which match an ignore pattern get output, one per line. and if no pattern matches a given path? nothing gets output for that path β€” which means that path will not be ignored. πŸŽ€

if --verbose is specified, the output is a series of lines of the form:

<source> <COLON> <linenum> <COLON> <pattern> <HT> <pathname>

so: <pathname> is the path of a file being queried, <pattern> is the matching pattern, <source> is the pattern's source file, and <linenum> is the line number of the pattern within that source. and if the pattern contained a "!" prefix or "/" suffix, it will be preserved in the output ✨. <source> will be an absolute path when referring to the file configured by core.excludesFile, or relative to the repository root when referring to .git/info/exclude or a per-directory exclude file. iykyk πŸ’…

if -z is specified, the pathnames in the output are delimited by the null character; and if --verbose is also specified then null characters are also used instead of colons and hard tabs:

<source> <NULL> <linenum> <NULL> <pattern> <NULL> <pathname> <NULL>

if -n or --non-matching are specified, non-matching pathnames will also be output, in which case all fields in each output record except for <pathname> will be empty. this is lowkey so useful when running non-interactively β€” files can be incrementally streamed to STDIN of a long-running check-ignore process, and for each of these files, STDOUT will indicate whether that file matched a pattern or not. (without this option, it would be impossible to tell whether the absence of output for a given file meant that it didn't match any pattern, or that the output hadn't been generated yet.) πŸ”₯

buffering happens as documented under the GIT_FLUSH option in git(1). ⚠️ and the caller is responsible for avoiding deadlocks caused by overfilling an input buffer or reading from an empty output buffer. don't do that to yourself bestie 😭


⭐ EXIT STATUS ⭐

  • 0 β€” one or more of the provided paths is ignored. slay πŸ’…
  • 1 β€” none of the provided paths are ignored. πŸ’€
  • 128 β€” a fatal error was encountered. πŸ™ˆ

🌸 SEE ALSO 🌸

gitignore(5) git-config(1) git-ls-files(1)


πŸ‘‘ GIT πŸ‘‘

part of the git(1) suite 🫢


and that's the whole page bestie β€” Git 2.56.0, dated 2026-09-27, no cap. go forth and check-ignore your heart out πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from