Prompt
Describe the git bisect workflow to find a commit that introduced a bug. Then write a script that automates git bisect with a test command.
Solution
Bisect turns "somewhere in the last 500 commits" into nine checkouts: it binary-searches history, so the cost is O(log n) test runs instead of the O(n) of reading diffs — 1,000 commits is ~10 steps. The prerequisite is one honest good reference (a release tag beats a guess: a wrongly-marked good sends the whole search into the wrong half, and that failure mode is silent).
git bisect run is the senior move: hand it any command and it drives the entire search unattended, deciding by exit code — 0 marks the commit good, 1–124 bad, and 125 means skip (this commit can't be tested at all, e.g. it doesn't build). The command doesn't have to be your test suite; a five-line script that greps output or curls an endpoint works, and writing a targeted repro script usually beats running the full suite at every step.
What bisect quietly rewards is the hygiene you had months earlier: small atomic commits that each build and pass. If half your history is broken mid-refactor commits, every bisect turns into a skip-fest — "every commit green" is not ceremony, it's what keeps bisect usable. Finish with git bisect reset to return to your original HEAD.
Red flag: answering "I'd read through the recent diffs" — that's linear search performed by the most expensive CPU in the room. Name the binary search and the automation.
Say it: "I give bisect one known-good tag and a repro script, and git bisect run binary-searches history unattended — exit code 125 skips unbuildable commits, and small green commits are what make it land on one culprit."