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.

I’ve used it only once to find a bug in a section of code at a company I was working for that both me and the other engineer I was working with did not know the history of. We were able to triangulate effectively the root of the pre-existing bug, and kind of how it was introduced, because of the surrounding history. Very useful tool for this purpose, albeit one that I use very infrequently.

Have you ever used git bisect?

Yup. A few times a year.

If so, how did you use it? Did it help you find a problem which would otherwise be difficult to find?

It helps me track down regressions, as in “this used to work, didn’t it?” or worse “haven’t I fixed this before?”.

I start a bisect, pick something relatively old, check if it works there, rinse, repeat.

I’ve done the exact same process by hand, good to know there’s a way to automate it (to an extent)

Several times, sometimes to find out when an incompatibility was introduced in an upstream dependency to find the maximum compatible version, but usually to find the commit that introduced a strange bug.

The process is always the same… Write a unit test, start bisect, check test select next bisect step, repeat. If your last-known-good and first-known-bad are correct, it always worked for me.

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

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.

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.

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.