Whitelist-first .gitignore pattern proposed to block accidental commits of secrets and junk

A case for default-deny in .gitignore

A blog post on packagemain.tech, picked up on Hacker News's front page, proposes that Git users invert their .gitignore files: instead of tracking everything by default and listing exceptions, ignore everything and explicitly admit only the files a project actually needs. The technique is a few lines long, but it targets one of the oldest footguns in version control.

The accident it is meant to prevent

According to the post, the scenario is familiar to most developers. Work proceeds, commits pile up, and at some point you notice the repository has collected .DS_Store files, node_modules, IDE configuration or other local artifacts, with CLAUDE.md named as one contemporary example. The genuinely dangerous variant is committing environment variable files, which can put credentials in front of anyone who can read the repository. The aftermath is unpleasant: add the offending files to .gitignore, strip them from the repository's history, and hope nobody noticed.

How the allowlist pattern works

Git's ignore syntax can negate itself: a line beginning with an exclamation mark re-includes paths that an earlier rule excluded. The post's example for a Go project starts with a lone asterisk, which ignores everything, followed by exceptions for the .gitignore file itself, Go source files matching *.go, go.mod, go.sum, and anything else the developer deliberately adds. Nothing else gets tracked, so a stray local file cannot slip into a commit simply because nobody remembered to exclude it.

The post closes with a practical footnote: Git ships a command, git check-ignore, that reports whether a given path is being ignored, which spares developers confusion when an expected file fails to appear as trackable. In a brief aside, the author also recommends lazygit as a terminal UI for Git worth trying.

What the author concedes

The technique is not presented as universal. The author acknowledges it may not suit every repository or developer, positioning it as an alternative worth exploring rather than a new default. The implicit trade-off is maintenance: under default-deny, every new category of legitimate file, from templates to fixtures to generated assets, needs its own exception or it will silently stay untracked.

The post also hints at why the idea feels timely. Conventional ignore lists keep growing, and the author points to typescript-go's .gitignore, which runs to 207 lines. Meanwhile, local working directories increasingly accumulate agent-generated documentation and ad-hoc subfolders. When the junk is open-ended and hard to predict, the argument goes, it is simpler to start from ignoring everything and open specific doors than to chase every new piece of clutter.

Why it matters

The .gitignore file encodes an assumption: that developers can enumerate everything they do not want in a repository. That assumption ages poorly as tools, especially AI coding agents, scatter more generated files across working directories, and a single missed entry can mean a committed secret, which is far harder to walk back than an untracked file. Flipping the default reverses the failure mode: forgetting to allow a file leaves it untracked and visibly missing from commits, rather than silently published. For repositories that touch credentials, that is a cheap structural guardrail. For everyone else, it is a useful reminder that allowlists and blocklists fail in opposite directions, and only one of those failures is embarrassing.