I committed a 200 MB file once. Never again — so I built a zero-dep pre-commit guard.

Everyone has a version of this story. Mine: I git add -A'd in a hurry, a

stray build artifact came along for the ride, and a few commits later the repo

had a 200 MB binary baked into its history. Cloning got slow for the whole team.

Fixing it meant git filter-repo, a force-push, and a Slack message that began

with "sorry, everyone needs to re-clone."

The cheaper versions are just as annoying: an accidental node_modules/, a

dist/ folder, a database dump, a .DS_Store. And the genuinely scary one — a

.env or a *.pem — where the moment it's pushed, the secret is burned and

rotating it is the good outcome.

The thing all of these share: they're trivial to prevent and expensive to undo.

Once it's in history, it's a rewrite. The leverage is entirely at the moment

before the commit.

"Just use .gitignore"

Sure — for the files you remembered to list. But .gitignore is a fixed list

you maintain by hand, and it's quietly easy to defeat:

• a git add -f walks straight past it,


• a file that was committed before you added the ignore rule stays tracked,


• a fresh clone of a template repo arrives with half the rules missing.

.gitignore is a default. What I wanted was a guard — something that looks

at what's actually staged, right before it becomes a commit, and stops me.

So I built bloatguard: one CLI, zero dependencies, Node and Python.

What it does

It flags two things in whatever you're about to commit:

1. 
   Big files — anything over --max-size (default 5 MB), whatever it is.
   This is the 200 MB binary catch.


2. 
   Junk patterns — a curated set that almost never belongs in git:
   node_modules/, dist/, build/, target/, *.log, *.zip, *.sqlite,
   .env (but not .env.example), *.pem, *.key, .DS_Store, and friends.
   

$ git commit -m "wip"

bloatguard 3 item(s) should not be committed (14 staged file(s) scanned)



  ✗ node_modules/ (1,240 files, 88.4 MB)  — dependency directory — reinstall instead of committing

  ✗ assets/demo.mp4 (84.0 MB)  — larger than the 5.0 MB limit

  ✗ .env (412 B)  — .env file — may contain secrets



Fix: add the pattern to .gitignore then git rm --cached <file>, or keep it on purpose with --allow <glob> / --max-size <size>

That whole node_modules/ — 1,240 files — collapses into a single line with a

count and total size, instead of scrolling your terminal off the screen.

Wire it into the commit

npx bloatguard install      # writes .git/hooks/pre-commit

# or: pip install bloatguard && bloatguard install

Now a commit that stages anything flagged exits non-zero and is blocked

before it happens. Fix it (or --allow it on purpose) and commit again. It

refuses to clobber a pre-commit hook you already have, and bloatguard uninstall

removes it cleanly.

You can also just run it ad hoc — bloatguard scans the staged set, bloatguard

scan sweeps the whole working tree (honoring .gitignore), --json for tooling.

A few choices I'd defend

• 
  Read-only, always. bloatguard never stages, modifies, or deletes anything.
  It reports and sets an exit code; the fix is yours. A tool that auto-git rms
  your files is a tool you stop trusting.


• 
  No false-positive theater. .env.example / .env.sample are explicitly
  spared; --allow "assets/*.zip" whitelists the archive you do commit on
  purpose. A guard that cries wolf gets git commit --no-verify'd into oblivion,
  and then it's protecting nothing.


• 
  Zero dependencies, two languages. Pure stdlib on both sides, and the Node
  and Python ports sort their input so they emit byte-identical output — a
  mixed-language team gets one answer.

MIT, both repos public:

.

I want to grow the junk list sensibly. What's the worst thing you've watched

go into a repo — and what pattern would've caught it? Terraform state? Jupyter

checkpoints? A 2 GB ML model? Tell me and I'll add a rule.