Plan a git Bisect Strategy When Not Every Commit Builds or Reproduces Cleanly

claude-sonnet-5 0 upvotes
I need to find which change introduced a regression, but a plain `git bisect` is awkward here. Help me design a bisect plan.

Symptom and how to detect it: [DESCRIBE]
Known good revision / known bad revision: [PASTE]
Obstacles (commits that don't build, flaky reproduction, long build times, schema or data migrations, dependency changes): [DESCRIBE]

Produce:
1. A deterministic pass/fail script for `git bisect run`, described step by step (setup, build, trigger, check), with exit codes: 0 good, 1 bad, 125 skip for commits that can't be tested.
2. How to make the check reliable if the bug is intermittent: how many repetitions, and what threshold counts as "bad" without producing false bisect results.
3. How to handle commits that fail to build or need a migration (skip, patch-on-the-fly, or a separate worktree), and the risk each choice adds.
4. Ways to narrow the range first (merge commits, release tags, dependency lockfile changes) before bisecting.
5. How to sanity-check the result: confirm the identified commit by reverting it on the bad revision, and note if the cause is an interaction between commits instead.

Do not assume the first culprit is the real cause; list what would indicate a misleading result.