cross-posted from: https://programming.dev/post/214031
Have you ever used
git bisect? If so, how did you use it? Did it help you find a problem which would otherwise be difficult to find? Story time, I guess?
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.
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.
