I’ve used it to fix regressions, most recently in a register allocator for a compiler. There’s pretty much no chance I would’ve found that particular bug otherwise; it was caused by an innocuous change (one of those “this shouldn’t matter” things) clashing badly with an incorrect assumption baked into a completely different part of the allocator.

I had seen the same effect from an unrelated bug on a different program. When I added a new test and saw the same effect, I had a “didn’t I fix this already?” moment. When I saw that the previous fix was still there, I checked if an older version of the allocator exhibited the same bug on the new test, and it did not. Bisecting found the offending change relatively quickly and further conventional testing exposed the incorrect assumption.

Yeah, a few times. It was especially helpful in finding causes of subtle UI bugs, to identify the exact commit which changed the UI.

A lot of times. It doesn’t really help to find a problem, but rather when the problem was introduced. It’s a really great tool.

Yes, once. Our research lab’s in-house software suddenly started throwing segfaults. The update was from the Mac side (OS), not the software side, so it would’ve been near impossible to figure out exactly which feature of the software no longer played nice with the new MacOS. We (me and a mentor) used git bisect to figure out what feature didn’t work, and patched it for the new OS update.

The next week I went and bought a new laptop and installed Linux on it so that didn’t happen again.