Bisecting a Bug

Something used to work. Now it doesn't. Somewhere between "fine last month" and "broken today" sits the one change that did it - buried in a hundred commits, or a thousand-line config, or a giant input file. The slow, miserable way is to check suspects one at a time until you stumble onto it. There's a far faster way, and it's the same trick whether you're hunting a commit, a line, or a row.

This guide teaches you to find the needle by repeatedly throwing away half the haystack. You'll learn the idea first, then git bisect (the tool that does it for commits, automatically if you let it), then how to apply the very same method to anything that has a "before it worked / now it's broken" shape.

How to read this

• Need to find the bad commit right now? Jump to Phase 2: git bisect - it's a full annotated session you can follow step by step.
• Want the idea to stick for life? Read in order. Phase 1 installs the mental model that makes everything else obvious, and Phase 3 shows you how far it reaches beyond Git.

The phases

1. Binary-Search Thinking - the powerful idea: halve the suspect range each test, so the search cost grows by adding one check when the haystack doubles. The three things you need to do it at all.
2. git bisect - the hands-on tool: mark one known-good and one known-bad commit, test each midpoint Git hands you, and let it name the exact first bad commit. Plus git bisect run to automate the whole thing.
3. Bisecting Beyond Git - the method generalizes: halving to find which config line, which input row, which dependency, or which block of code is the culprit - and the one thing that quietly ruins every bisect if you skip it.

Deep rewriting-history rescue (when a bisect or a fix leaves your branch in a tangle) lives in Git Disaster Recovery. This guide stays focused on finding the bad change, not surgically removing it.