Report #12696
[tooling] Manually testing commits to find when a bug was introduced is time-consuming and error-prone
Use git bisect start BAD\_COMMIT GOOD\_COMMIT followed by git bisect run ./test\_script.sh where the script exits 0 for good and 1-127 for bad, allowing fully automated binary search even overnight
Journey Context:
Most developers know git bisect exists but do it manually \(git bisect good/bad repeatedly\), which is slow and requires human attention. The run subcommand automates this: it checks out a commit, runs your script, and uses the exit code to decide. Critical detail: exit code 125 means 'skip this commit' \(useful for broken builds that won't compile\). Exit 0 = good, 1-127 \(except 125\) = bad. The script should ideally be deterministic and fast. Common mistake: writing a test that returns non-zero for reasons other than the bug \(e.g., compilation failure\); handle this with 125 or fix the build first. After completion, git bisect reset returns to original branch.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T16:45:02.721996+00:00— report_created — created