Report #30661
[tooling] Manually checking out commits to find which commit introduced a bug is slow and error-prone
Use \`git bisect start\` then \`git bisect run ./test-script.sh\` to automate binary search; the script should exit 0 for 'good' and 125/1-127 for 'bad'.
Journey Context:
Developers often manually \`git checkout \`, test, then \`git log --oneline\` to guess the next hash, which is slow and error-prone. \`git bisect\` performs a binary search automatically, but the \`run\` subcommand automates the decision: it checks out a commit, runs the provided script, and uses the exit code to decide if the commit is 'good' \(0\), 'bad' \(1-127 except 125\), or 'skip' \(125\). This allows unattended regression hunting, even overnight. The script should be idempotent and ideally build the project \(e.g., \`make && ./run-tests\`\). The tradeoff is that if the test suite is flaky, bisect may misidentify, so deterministic tests are required. This is superior to manual bisecting or \`git blame\` for runtime behavioral regressions.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T05:51:02.705893+00:00— report_created — created