{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}

Use git check-ignore -v to confirm uncommon patterns or rules from multiple ignore sources.
{{ gitignoreMeta }}
{{ sourceStatus.gitignore || 'Drop one .gitignore or TXT file up to 1 MiB onto the textarea.' }}
This label stays in the browser and appears only in exported review artifacts.
The gate is strict: every selected path must be covered and no tracked cleanup or blocked negation may remain.
%
Separate selectors with commas or new lines. Review the selected path ledger before relying on the percentage.
Duplicate paths are counted once. Rename and copy rows use the destination path.
{{ pathMeta }}
{{ sourceStatus.file_paths || 'Drop one TXT, LOG, or CSV path inventory up to 1 MiB onto the textarea.' }}
{{ workflowFeedback }}
The default follows normal Git matching and does not alter the result merely by opening Advanced.
Repository pathPath classGit stateOutcomeWinning ruleNext actionCopy
{{ row.path }}{{ row.path_class }}{{ row.git_state }}{{ outcomeLabel(row.outcome) }}{{ row.winning_rule }}{{ row.next_action }}
PriorityFindingEvidenceSuggested next stepCopy
{{ row.priority }}{{ row.finding }}{{ row.evidence }}{{ row.next_step }}
LinePatternBehaviorStateMatchesReview noteCopy
{{ row.line }}{{ row.pattern }}{{ row.behavior }}{{ ruleStateLabel(row.state) }}{{ row.match_count }}{{ row.note }}
.gitignore Generator Build a repository-ready .gitignore from your stack and team setup, with secret-file exceptions and warnings for broad or duplicate rules.
Secret Pattern Sample Checker Scan config, log and ticket samples for secret-like values with masked findings plus provider signatures, entropy scoring and rotation guidance.
.env File Generator Generate reviewed .env and .env.example files with key cleanup and secret-aware placeholders while flagging quote or duplicate risks locally.
Conventional Commit Messages Checker Check Conventional Commit headers or full messages against repository rules and see each valid message’s release impact before publishing.

Ignore rules are most useful when they express a shared repository boundary. Generated builds, downloaded dependencies, coverage output, editor files, and local environment settings can otherwise crowd status output or enter a commit even though another machine can recreate them.

A .gitignore file applies only to intentionally untracked paths. Adding a rule after a file has entered the index does not make that tracked file disappear. The index must be cleaned separately, with the local copy kept or removed according to the project’s intent.

Pattern order also changes the answer. Git evaluates matching rules in sequence, and the last applicable rule determines whether a path stays ignored or becomes visible again. A leading ! creates an exception, but an ignored parent directory can prevent Git from reaching a child that an exception tries to restore.

Shared ignore
A committed .gitignore rule that should behave the same for every clone.
Candidate path
A sampled path selected for review because it resembles generated output, local configuration, a report, or sensitive material.
Winning rule
The last matching ignore or negation rule used to classify one path.
Coverage
The share of selected candidate paths classified as ignored, including paths that may still need tracked-file cleanup or negation review.

A coverage percentage is therefore a screening measure, not proof that the repository is clean. The sample may omit an important path, a tracked file remains tracked despite matching a rule, and other ignore sources can change Git’s real decision. The safest conclusion comes from combining representative paths with Git’s own verbose ignore check.

How to Use This Tool:

Build the review around paths that should not enter the shared history, then compare the simulated result with Git where the pattern is unusual.

  1. Paste or load the repository-level rules into .gitignore rules. Keep rule order unchanged because later matches can override earlier ones.
  2. Set Generated or sensitive selectors to the path names or globs that define the audit set, such as dist/, .env*, or *.pem.
  3. Paste plain paths, short status output, porcelain-v1 rows, or name-status output into Repository paths. Duplicate paths count once, and rename or copy rows use the destination path.
  4. Choose the Coverage target and leave Path case matching on the case-sensitive Git default unless the worktree genuinely needs a case-insensitive audit.
  5. Read the summary together with the Path coverage ledger. Resolve uncovered paths, tracked cleanup, invalid rules, and blocked negations before treating the gate as clear.
  6. Confirm consequential or surprising matches with git check-ignore -v <path> in the real repository.

Interpreting Results:

Covered means the bounded matcher found an ignore result for that selected path. Uncovered means no ignore result remained after rule order was applied. Re-included identifies a selected path exposed by a negation, while Blocked negation means an ignored parent prevents the child exception from working as intended.

  • A high percentage can coexist with a failed gate because tracked files, blocked negations, or invalid rules are independent blockers.
  • Tracked cleanup requires an index decision; adding another ignore pattern does not stop tracking.
  • Inactive or broad rules deserve review, but neither one alone enters the blocking-finding count.
  • The candidate ledger defines the denominator. Check that the selectors captured every path class that matters before relying on the percentage.

Technical Details:

The analysis first normalizes path separators, removes leading ./ or /, collapses repeated slashes, and keeps at most 5,000 unique paths. Status markers distinguish untracked, reported-ignored, and tracked rows. Only paths matched by at least one generated-or-sensitive selector become candidates.

Rule Core

Rules are evaluated from top to bottom. Blank lines and comments are skipped; escaped leading # and ! remain literal. The matcher supports slash anchoring, directory patterns, *, ?, bracket classes, and double-star globs. Unmatched bracket classes and dangling escapes make a rule invalid.

Order Decision Recorded outcome
1 The path matches none of the review selectors. Excluded from the candidate denominator.
2 Each valid ignore rule is applied in source order; the last applicable rule wins. Ignored or visible.
3 A negation matches, but an earlier ignored parent is still in force. Blocked negation and ignored.
4 The winning rule is a usable negation with no blocked parent. Re-included and visible.
5 An ignored candidate is already tracked. Tracked cleanup, even though the rule matches.

Formula Core

Coverage uses only selected candidate paths. It is displayed as a percentage, while the shortfall is measured in percentage points.

C= NignoredNcandidate ×100
G=max(0,Ctarget−C)

The gate passes only when coverage reaches the chosen target and the counts for uncovered candidates, tracked cleanup, blocked negations, and invalid rules are all zero. The blocking-finding total is the sum of those four counts. Re-included paths and rules with no selected match remain review evidence but are not gate blockers.

Limitations and Privacy Notes:

The rules and path inventory are processed in the browser. The repository label is used only in local review artifacts. The matcher models one repository-level ignore file and a bounded subset of Git behavior; it does not read nested ignore files, repository-local excludes, global excludes, attributes, sparse-checkout rules, or the index itself.

  • Use Git’s own check-ignore -v output when multiple ignore sources or uncommon patterns may affect a path.
  • Do not paste secret values. Path names and status output can reveal project structure even when file contents are absent.
  • A sampled inventory cannot prove future generated paths are covered; rerun the review when build outputs or repository layout change.

References: