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.

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

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 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.

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.

I use it regularly in projects from other people, almost never in mines. It’s a good tool when I’m completely in the dark, not knowing much about the architecture of the codebase. When I do know the architecture, I usually have a good intuition where the problem is coming from and I go poke the git log of the file or files related to that, it’s always faster than bisecting. But in Terra Incognita, this is an incredibly powerful tool. You know this version worked, you know this one is broken, and you can just follow the process of git bisect to find the exact commit that introduced it. In FOSS projects, it’s usually a commit that changes two or three lines and you can pinpoint immediately what the problems is. If it’s a 1000 LOC change commit, you’re in for more analysis, but at least you know it’s somewhere there. :) So yeah, I would call that mostly a tool to contribute bugfixes in FOSS projects, at least in my usage.

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

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.