In Git, how do you find which ignore file and line is excluding a specific path?

## The problem it solves A path can be excluded by a pattern in the directory next to it, in any parent directory up to the top of the work tree, in `.git/info/exclude`, or in the personal file named by `core.excludesFile`. Reading all of them by hand and applying "last match wins" mentally is slow and error prone. `git check-ignore` performs exactly the query Git performs and reports the verdict. ## Reading the verbose output With `-v`, each ignored path produces a line of four tab-separated fields: the source file, the line number within it, the pattern text, and the path itself. An output such as `.gitignore:12:*.log src/debug.log` tells you the decision came from line 12 of the root ignore file. When the source is reported as the global file or `.git/info/exclude`, you have just learned the rule is not in the repository at all, which is the usual explanation for "it works on my machine but not on the CI checkout", or the reverse. Without `-v`, the command simply echoes the paths that are ignored, which is what you want when scripting. ## Exit status `check-ignore` is a plumbing-flavoured command with meaningful exit codes: 0 if one or more of the given paths is ignored, 1 if none are, and 128 if a fatal error occurred. That makes a shell guard around `git check-ignore -q "$f"` clean to write, with `-q` suppressing output. ## The index interaction By default the command consults the index, matching Git's real behaviour that ignore rules do not apply to tracked paths. So a tracked file usually reports as not ignored even when a pattern matches its name. When you are investigating exactly that situation, for example a file that `git add .` picked up when you expected it to be skipped, pass `--no-index`: Git then answers the pure pattern question, ignoring whether the path is tracked. Comparing the two runs is the fastest way to distinguish "no rule matches" from "a rule matches but the file was already tracked". ## Companion commands - `git status --ignored` lists ignored paths alongside the normal status output, which answers "what is Git hiding from me in this tree". - `git ls-files --others --ignored --exclude-standard` enumerates untracked-but-ignored files, useful for auditing what a build leaves behind. - `git clean -Xn` previews removing only ignored files, a dry run worth doing before any `git clean` variant. - `git add -f <path>` force-adds a path despite the rules, which is the escape hatch when you genuinely want one exception without editing patterns. Note that `git add` on an ignored path otherwise refuses and prints a hint mentioning the force option. ## Multiple paths and stdin You can pass several paths at once, or feed them with `--stdin`, which pairs well with `-v -n` to produce a full verdict table for a generated list of files. That is how you audit whether a proposed ignore-file change would hide something it should not. ## Habits worth forming When a pattern "does not work", check three things in order: run `check-ignore -v` to see whether any rule matches at all; if a rule matches but the file is still showing up, suspect that the path is already tracked; if no rule matches, suspect anchoring, a trailing space, or a negation cancelled by a later broad pattern. Almost every ignore mystery falls into one of those three buckets, and the first command distinguishes them in a second.