I’ve done git bisect manually many times: mark good, mark bad, test, repeat. It works. It’s also tedious.

git bisect run takes a command. Git checks out each midpoint, runs the command, and uses the exit code to decide “good” (0) or “bad” (non-zero).

git bisect start
git bisect bad HEAD
git bisect good v1.2.0

git bisect run ./scripts/repro-bug.sh

Walk away. Come back in five minutes. Git has found the commit.

Two patterns I use:

  1. scripts/repro-bug.sh — a script that builds, runs, and checks for the bug. Exits 0 if no bug, 1 if bug present. This is the classic use.

  2. git bisect run make test-foo — when a specific test started failing and I want to find the commit.

The trick is that the command has to be self-contained. It can’t depend on the environment being set up — each bisect step is a fresh checkout. If your build takes a while, budget for that times log2(commits between good and bad).

Also: exit code 125 is special. It means “skip this commit, I couldn’t decide.” Useful for commits that don’t build at all. You can exit 125 in your script when building fails for infrastructure reasons.

Wish I’d reached for this sooner. Manual bisect still has its place (when tests take an hour and you’d rather not babysit), but for quick-to-run reproductions, this is magic.