I use it from time to time. Often I test manually instead of automatic, and it often works very well.

But if you want a story about an unconventional use of git bisect, I think there’s one about the time I had a directory with lots of files, and one of those files was causing some problem, but I didn’t know which one it was. Those files were not under version control, but I created a repo with them, where each file was added in a separate commit. Then I could use git bisect to find which file was causing the problems.

Multiple times.

Typically on high frequented repositories. If there are a hundred commits (or more) each day, suddenly merged from multiple branches and shit starts to go weird, it is sometimes not clear when exactly it started to go south. So I write a test to reproduce the problem and then let git bisect checkout, run test, etc. until it can tell me which revision it first occurred in.

One time I also had to find out when a specific functionality in a microcontroller broke. I have forgotten, why we knew it worked before without having it covered in a test, though. The build-download-testrun-repeat-cycle took almost a day until it could pinpoint the revision. That was fun. But it nailed it to a single line and was right with it.