IgnoreDebugger is a small web tool for working out why Git is — or isn't — ignoring a particular file. You paste a file path and your.gitignore rules, and it tells you which rule decided the outcome, and why that rule was the one that counted.
What it is
The tool itself sits on the home page, where it is titled the Gitignore Debugger. It does one thing: it re-implements the matching rules Git applies to .gitignore patterns — anchoring, wildcards, directory-only rules, negation and rule precedence — and then reports the deciding line instead of a bare yes or no.
It is an independent project. It is not affiliated with the Git project and it is not a replacement for git check-ignore; it is a quicker way to answer the question when you don't have a repository in front of you.
The problem it solves
A file that refuses to be ignored is a genuinely awkward thing to debug. git status will tell you a file is still showing up, but not which rule failed to catch it.git check-ignore -v does name the deciding rule, but it needs a repository, a terminal and a real path on disk — which is no help when you are reviewing someone else's .gitignore in a pull request, drafting a rule you haven't committed yet, or reasoning about a path that only exists on a colleague's machine.
Most of the confusion comes from a handful of behaviours that are easy to miss: the last matching rule wins rather than the first, a! negation cannot rescue a file out of an already-ignored directory, a pattern containing a slash is anchored while one without a slash matches at any depth, and .gitignore has no effect at all on files Git is already tracking. Seeing the specific line that matched usually makes the cause obvious straight away.
Who it is for
- developers whose file is being ignored — or stubbornly not being ignored — for reasons that aren't obvious
- anyone writing or reviewing
.gitignorechanges and wanting to check a pattern before committing it - people learning the pattern syntax, where a worked example is worth more than the documentation
- teams maintaining a shared ignore file that has grown long enough for rules to start quietly overriding each other
Everything runs in your browser
The matching engine is ordinary JavaScript, downloaded once with the page and then run entirely on your own machine. When you pressDebug this file, no network request is made: the path and the rules you typed are compared locally and never uploaded. There are no accounts to create and nothing to sign in to.
That matters because a real .gitignore often names internal services, directory layouts and credential files. Pasting one here does not disclose it. The privacy policy sets out the detail.
Accuracy, and what it can't tell you
The engine's behaviour is checked against the output of realgit check-ignore runs, and it has a test suite covering the pattern syntax — including the fiddly corners like character classes, escaped trailing spaces and the three positions where** is meaningful.
It is still worth being clear about the limits. The tool only knows what you paste into it: it cannot see your repository, so it cannot tell you whether a file is already tracked, and it does not go looking for nested .gitignore files,.git/info/exclude or a globalcore.excludesFile on your behalf. For anything that depends on the actual state of a repository,git check-ignore -v andgit status --ignored remain the authority.
Contact
Questions, bug reports and corrections are welcome — particularly a pattern you believe is handled incorrectly. If you send the file path and the rules alongside it, the case can be reproduced and tested directly.
Contact: admin@ignoredebugger.com