.gitignore Pattern Coverage Checker

Ignore coverage is a repository hygiene check. It asks whether generated output, dependency caches, local environment values, coverage reports, operating-system clutter, and secret-like artifacts are actually kept out of the next commit by the current ignore rules.

The answer can be less obvious than the rule list suggests. Git ignore patterns use ordering, slash placement, directory-only patterns, glob characters, escaped characters, and negation. A later rule can override an earlier one, and a negation rule cannot rescue a child path when an excluded parent directory prevents Git from walking into it. A path that already sits in the index is a separate problem because ignore rules do not stop Git from tracking something it already tracks.

Coverage is most useful when it stays tied to concrete paths. A broad rule such as build/ may cover the sample paths from one project, while the same repository can still leak tmp/cache.db, .env.production, or secrets/prod.pem if those names are outside the chosen terms and patterns. The practical review brief keeps the candidate path, the winning rule, and the next action together.

A clear result does not prove that every future generated path is covered. It means the pasted path sample, generated or sensitive terms, and ignore rules agree under the selected case mode.

Technical Details:

Git ignore matching is ordered pattern matching over pathnames. Blank lines and comment lines are skipped, trailing spaces are ignored unless escaped, and a leading escaped hash or exclamation mark is treated as a literal character. A leading ! changes a later match into a re-include rule, while a trailing slash makes a pattern directory-only.

Slash placement changes the search area. A pattern with a slash at the beginning or middle is anchored relative to the ignore file level being modeled, while a pattern without a slash can match below that level. Single asterisks and question marks do not cross slash boundaries. Double-star forms can match across directory levels when used in the supported positions.

Rule Core

Each repository path is tested against the usable rules in order. The final matching rule decides the ignored state, except when a negation tries to re-include a child path under a parent directory that was already excluded. That parent-directory case is important because Git avoids listing excluded directories, so a child exception may never be reached by a real status scan.

Candidate selection is separate from ignore matching. The generated or sensitive terms decide which repository paths enter the coverage denominator. Literal terms can match path segments, environment-style dotnames, or nested path prefixes. Glob terms are tested with the same slash-aware matching model used for ignore rules.

The gate is stricter than the percentage alone. It requires at least one candidate path, coverage at or above the target, no uncovered candidates, no ignored paths already marked as tracked, no blocked negations, and no invalid rules. That prevents a high percentage from hiding a single secret-like path, a tracked generated artifact, or a broken exception rule.

Everyday Use & Decision Guide:

Start with the repository-level ignore rules you expect teammates to share, then paste a realistic path inventory from the same repository. A useful first pass is git status --short, git diff --name-status, or one path per line from a file listing. Status rows matter because tracked generated paths need index cleanup, not just another ignore rule.

Keep Generated or sensitive terms narrow enough to describe the risk being reviewed. Common terms include node_modules/, dist/, build/, coverage/, .env*, *.pem, and .DS_Store. Add project-specific folders such as tmp/cache/ or reports/ when those paths appear in your inventory.

• Use Coverage target as a review gate. The default 95% target is useful for a quick audit, but a secret-handling review should treat any uncovered secret-like candidate as blocking.
• Use Path case matching carefully. Default Git behavior is case-sensitive, while case-insensitive audit mode is only appropriate for repositories configured that way.
• Open Coverage Gate Metrics first to see candidate count, ignored count, tracked cleanup items, negation exceptions, invalid rules, and target status.
• Use Path Ignore Ledger for path-by-path evidence. It shows the path class, Git state, outcome, winning rule, and recommended action.
• Use Pattern Audit Queue to find inactive rules, broad patterns, invalid lines, and negations that touch generated or sensitive candidates.
• Use Ignore Coverage by Path Class when the problem is clustered. Dependency caches, build output, coverage reports, secret-like paths, and editor clutter often need different fixes.

The result is only as complete as the pasted path sample. If a monorepo has several package managers or build systems, include paths from each workspace before trusting the coverage percentage. A clean sample from one app does not cover another app that writes to a different output folder.

When the summary says ignore review queued, work the ledger before copying JSON or table rows into a review note. The most important rows are uncovered secret-like paths, tracked cleanup items, invalid rules, and blocked negations.

Step-by-Step Guide:

Review one repository or one coherent workspace at a time so the target percentage and path classes describe the same ignore policy.

1. Enter a short Repository label so copied evidence and JSON identify the project being checked.
2. Set Coverage target to the review threshold you want to enforce.
3. List generated or sensitive selectors in Generated or sensitive terms. Use one term per line when the list is long.
4. Paste, browse, drop, or load a sample into .gitignore rules. The source badge should report active rules, negations, and invalid lines.
5. Paste, browse, drop, or reset Repository paths. The path badge should show parsed paths and selected candidates.
6. Open Advanced only if the repository needs case-insensitive matching for this audit.
7. Check Coverage Gate Metrics. If errors appear above the results, restore the missing terms, usable rules, or path inventory first.
8. Move through Path Ignore Ledger and Pattern Audit Queue until uncovered candidates, invalid rules, tracked cleanup rows, and blocked negations are resolved or documented.

A strong handoff has a nonzero candidate count, a coverage percentage that meets the target, no uncovered sensitive candidates, and no tracked generated paths left in the pasted status sample.

Interpreting Results:

The headline percentage counts candidate paths ignored by the final winning rule. Read it with the badges beside it. A high percentage can still require work when one candidate is uncovered, one ignored path is already tracked, a negation is blocked by an excluded parent directory, or a rule line is invalid.

Tracked cleanup is easy to misread. It means the ignore rule may be correct for future untracked files, but the pasted status row says the path is already in Git. The normal cleanup path is to remove that generated or sensitive artifact from the index after confirming it should stay out of version control.

Pattern Audit Queue is the best place to spot rules that look useful but do not affect the pasted sample. Inactive rules may be harmless leftovers, but they can also show that the path inventory is too narrow or that the term list is missing a generated class. Broad rules such as * should be reviewed with their exceptions because they can hide more than intended.

Use the chart as a clustering aid, not as the final answer. Fix rows in the ledger first, then use the path-class view to decide whether a single rule can handle a whole category or whether several project-specific paths need separate entries.

Worked Examples:

Build output with one intentional README. A repository ignores dist/ and later adds !dist/README.md. The path list includes dist/app.js and dist/README.md. The ledger marks the app output as covered and the README as re-included. If the README is hand-maintained, the exception is reasonable; if it is generated, remove the negation or move the maintained note outside the generated folder.

Secret-like path missed by a narrow term list. A sample includes .env.local, secrets/prod.pem, and config/private.key. Terms that only name .env* and *.pem will select the first two but not the key file. Add *.key or a project-specific config/private.key term before treating the denominator as complete.

Tracked dependency cache. A status sample marks A node_modules/vue/index.js while the rule list includes node_modules/. The ignore rule covers future untracked dependency files, but the ledger still flags tracked cleanup because this path is already staged or tracked. The remediation is index cleanup, not a duplicate node_modules/** rule.

Blocked child exception. A rule list ignores build/ and later tries !build/manifest.json. If the parent directory remains excluded, the child exception can be blocked. Reopen the parent path intentionally before relying on the manifest exception.

Responsible Use Note:

Ignore audits often include private repository names, local environment paths, secret-like filenames, and evidence that a sensitive artifact nearly entered version control. Paste the smallest path sample that still proves the review point, especially when working with client projects or incident cleanup.

The calculation runs in the browser session, and browsed text files are read locally by the page. Copied tables, chart images, and JSON can still contain sensitive path names and rule text, so treat those outputs as repository review evidence.

FAQ:

Glossary:

Candidate path

A pasted repository path selected by one or more generated or sensitive terms.

Winning rule

The final matching ignore rule that decides whether a path is ignored or visible.

Negation

A rule beginning with ! that attempts to re-include a path matched by an earlier ignore rule.

Blocked negation

A child re-include rule that cannot work because an earlier rule excluded a parent directory.

Tracked cleanup

A candidate path that matches ignore rules but is already tracked or staged according to the pasted status row.

Coverage target

The minimum ignored-candidate percentage required before the gate can clear.

References:

• Git gitignore documentation for pattern order, slash behavior, negation, double-star matching, and tracked-file limits.
• Git check-ignore documentation for debugging which pattern matched a path and why tracked paths need separate handling.