Bisecting a Bug (git bisect & Binary-Search Thinking)

When something worked before and is broken now, you don't search commit by commit - you halve the suspect range each test, so 1000 commits take about 10 checks; git bisect automates the hunt, and the same halving idea finds the bad config line, input row, or dependency.

1. Binary-Search Thinking - Halving the Haystack When something worked before and is broken now, you don't test suspects one by one - you test the midpoint, throw away the half you just cleared, and repeat; doubling the haystack adds only one more check, so a thousand commits take about ten.
2. git bisect - Letting Git Drive the Search Tell Git one known-good commit and one known-bad commit; it checks out the midpoint, you test and mark it good or bad, and after about ten rounds it names the exact first bad commit - then git bisect reset puts you back, and git bisect run automates the whole loop.
3. Bisecting Beyond Git - The Method Is Everywhere The halving idea isn't about commits - it's about any 'worked before / broken now' problem: which config line, which input row, which dependency, or which block of code is the culprit, all found by clearing half at a time; the one rule is that your yes/no test must be reliable, never flaky.