Putting a file in .gitignore does nothing if git already tracks it. I built a CLI to find the leftovers.

You added .env to .gitignore. You felt responsible. But three weeks later it's still in the repo, still pushed to GitHub, still in every clone — because adding a path to .gitignore does nothing to a file git already tracks.

That's not a bug. It's documented behavior: .gitignore only stops untracked files from being added. Anything already committed keeps getting tracked, ignore rule or not. So the secrets, build artifacts, and 40 MB log files that were committed before someone wrote the rule just... stay.

The fix is one command — git rm --cached — but only once someone notices. And nobody notices, because git status is clean and the file looks ignored.

So I built gitslip: a zero-dependency CLI that finds every tracked file your own ignore rules say should be gone, and hands you the exact fix.

$ npx gitslip

2 tracked files are ignored by your rules but still committed:

  config/secrets.env
      ↳ .gitignore:7  *.env
  logs/app.log
      ↳ .gitignore:2  *.log

Fix — stop tracking them (keeps your local copy):
  git rm --cached -- config/secrets.env
  git rm --cached -- logs/app.log

  or let gitslip do it:  gitslip --apply

It tells you which rule caught each file (.gitignore:7 *.env), so there's no guessing. And --apply runs the git rm --cached for you — it only un-tracks, it never deletes your working copy.

Why not just grep?

You can grep your .gitignore patterns against git ls-files. But:

A raw grep '\.env' can't tell a still-tracked leftover from a file that's correctly excluded, and it has no idea about !negation rules, build/ directory rules, nested .gitignore files, .git/info/exclude, or your global core.excludesFile.
Reimplementing gitignore's matching semantics to get this right is exactly the kind of subtly-wrong code you don't want guarding your secrets.

gitslip doesn't reimplement anything. It asks git.

How it works (the fun part)

Detection is a single git incantation:

git ls-files -i -c --exclude-standard

-c = tracked (cached), -i = ignored, --exclude-standard = use all the standard ignore sources. That's the authoritative "tracked and ignored" set, and git handles every negation/directory/nested rule correctly. No matching logic of our own = no disagreements with git.

The interesting part is naming the rule that caught each file. The obvious tool is git check-ignore -v... except it short-circuits: for a file git is already tracking, check-ignore reports "not ignored" and refuses to name a pattern. (And --no-index didn't reliably fix it on the git I tested.)

The trick: run check-ignore against an empty index.

GIT_INDEX_FILE=/tmp/empty git check-ignore -v -z --stdin

Point GIT_INDEX_FILE at a path that doesn't exist — git treats it as an empty index, so nothing is tracked, so check-ignore stops short-circuiting and happily names the matching .gitignore:line:pattern for every path. It's read-only, so the file is never even created.

Install

npx gitslip          # Node, zero deps
pip install gitslip  # Python, zero deps — byte-for-byte identical output

Both builds are pure standard library. There's a Node version and a Python version because half of you live in one ecosystem and half in the other, and they produce identical output down to the byte (I diff them in CI).

It's also a clean CI gate — exits 1 if anything slipped, so you can fail a build that's about to commit an ignored file:

- run: npx gitslip

Try it on your repo

Seriously, run npx gitslip in your current project right now. If you've ever git add -A'd before writing a .gitignore, there's a decent chance something's in there.

What's the worst thing you've found still tracked in a repo — a secret, a 100 MB binary, someone's .DS_Store from 2019? Tell me below.