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.

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.

Can’t remember details, so no particularly interesting story around it I guess. Just a couple of times when something had broken at an unknown point in time and I needed to figure out which commit. I’ve been using git almost since its inception, and in a work setting since maybe 2010. And in that time, I’ve used git-bisect maybe ten times. While that might make it sound like a useless feature, it is a life saver when you do need it.

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

4-5 times now. When confronted with more than a hundred commits between latest known working version and the one you’ve observed the bug (which was not catched by any of the unit tests) it can save some time to find the fishy commit.

In such a case I create a testcase on top to reproduce the bug. Then bisect and for each stage add the testcase, build, run tests. FYI: this only works if all (or at least most) of the commits in the chain are compilable - if you’ve done a big messy refactoring with several commits breaking the build, bisect can get you only so far.

https://feddit.de/comment/527050

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

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.

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.

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.

Yes, back in 2009, after a kernel update to 2.6.26 there was an intermittent and hard to reproduce problem with Intel’s e1000e ethernet linux kernel module. It only happened when some specific switches/hubs were connected to the interface; the interface would initialize in an unusable state (about 50% of the computer boots).

The e1000e module was used by a lot of Intel onboard ethernet interfaces, including the one used by Dell Vostro computers.

I found other people reporting it in the kernel’s bugzilla, and added my case.

The Intel developer couldn’t reproduce it (he didn’t have one of the switches that triggered the problem), so he asked me to use bisect to help narrowing down to the commit that started the problem.

Because it was an intermittent issue, I wrote a script to reboot the PC multiple times on each bisect try, to eliminate false positives.

(I didn’t remember all these details, but googled my name and bisect, and found the bugzilla thread; it’s an interesting bisect use case: https://bugzilla.kernel.org/show_bug.cgi?id=11998#c8 - no I don’t mind this associates my lemmy user name with my real name).

The bisect did locate the culprit commit, and after many other tests, it ended up being an issue with the MDI/MDIX (crossover or straight connection detection). The correction was pushed into the kernel.

Bisect definitely helped to find an important and otherwise difficult to find problem there.

Linux 5.17 introduced a null pointer deref in the md (multiple disks) module. That’s the first time I used bisect to find a faulty commit. The issue was fixed in a later release candidate.

It can be a pretty handy tool if you’re dealing with projects that have a high number of commits between releases.

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.

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.

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.

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.