Automating the installation and test, and then pointing `git bisect run script` at it is pretty damn awesome if you can automate it.

This is one of my absolute favourite things to do. There’s something so beautiful about having software automatically finding the bug for you.

This is why keeping good, linear history is so important. The software isn't magic. It won't be able to tell you where the bug is in that giant commit that touched every module in the codebase. Good history is your input to git bisect. It's the only reason (but an extremely compelling reason) to care about your git history.

Here is a bisect scenario that seems to be happening before my eyes.

I was using git bisect to find a problem. Let's call it issue A. During the bisect, I discovered that some builds are not testable at all. Let's assume that instance of that problem are all issue B. So the verdict from the git bisect is that there are four possible consecutive commits that could be the start of A.

But those four include commits afflicted with B, which seems related. Why it seems related is that the last of those four bad commits suddenly fixed B, so builds became testable, but introduced A.

Since I was bisecting for A, I don't have a complete list of commits afflicted with B; git bisect just happened to find three commits afflicted with B.

Thus I have to do a second git bisect, this time validating for issue B, to see where exactly the builds became untestable.

That will hopefully put together the story: something like: at commit X, a serious problem showed up, rendering builds untestable (issue B). Then at later commit Y, B was fixed but A started happening, which wasn't a problem before X.

Well, find the commit where the behavior is introduced, in any case.

Or, in some cases, multiple possible commits. If the bad commit is preceded or followed by untestable commits (declared that way via "git bisect skip", they are implicated also).