.gitignore Tester

Because git never looked at the file. When it walks the tree and finds that a directory is excluded, it stops there and does not descend, so no rule about anything inside that directory is ever evaluated — the documentation states it plainly: "It is not possible to re-include a file if a parent directory of that file is excluded." With logs/ and !logs/important.log, the log stays ignored, and this tester shows the decision coming from the directory rule. The fix is to exclude the contents instead of the directory: logs/* followed by !logs/important.log works, because logs/* matches the entries inside logs without excluding logs itself. For a whole subtree the recipe is /logs/**, then !/logs/keep/, then !/logs/keep/**.

A pattern with no slash anywhere in it is matched against the basename of every path, at every depth, so build ignores /build, /src/build and /a/b/c/build alike. As soon as the pattern contains a slash that is not its last character, it is anchored to the directory containing the .gitignore, so /build and docs/output only ever match from the root of that directory downward. This is why a bare node_modules in a root .gitignore also hides a nested package's node_modules — usually what people want, but not what they wrote down on purpose. The leading slash is the way to say "only here".

No. A trailing slash means the pattern only matches directories, so a plain file called logs is left alone while a directory called logs, at any depth, is ignored together with everything under it. This matters here because a pasted list of paths carries no type information: git decides by looking at the real filesystem, and this tester has to be told. Write logs/ in the path box for the directory and logs for the file — the same string with and without the slash can get opposite verdicts, and that is not a quirk of the tool but the reason git check-ignore sometimes disagrees with what people expect when the path does not exist yet.

A ** only has special meaning when it occupies a whole path segment. **/foo at the start matches foo at any depth, and is the explicit form of what a slashless pattern already does. A trailing foo/** matches everything inside foo — but not foo itself, which is exactly why the re-include recipe above works. And a/**/b in the middle matches a/b, a/x/b and a/x/y/b, zero or more directories included. Anywhere else, the stars are ordinary: a**b is just a*b, and a single * never crosses a slash, so src/*.c matches src/main.c but not src/lib/main.c.

.gitignore only ever applies to files git is not already tracking. Once a file has been committed, adding a pattern for it changes nothing: git keeps reporting its changes and keeps committing them. Untrack it first with git rm --cached path (which leaves the working copy in place) and commit that removal; from the next commit on, the ignore rule governs. This tester answers the untracked-file question — the one check-ignore answers — so a path it calls ignored can still show up in git status if it is in the index, and that is the first thing to check when the two disagree.

Git reads several sources in a fixed order and the more specific one wins: patterns from the command line, then .gitignore files, with a file in a deeper directory overriding one above it, then .git/info/exclude for repository-local rules that are not shared, and finally the global file named by core.excludesFile. Within one file the last matching line decides. This tester models a single .gitignore, so if its verdict disagrees with your repository, a nested .gitignore, an info/exclude entry or your global file is the likely culprit — run git check-ignore -v there and the source column will name the file.