Just yesterday 😅 there’s a bug in the main branch of Lemmy itself that I was trying to pinpoint (introduced after 0.18.0 was tagged). Instead of walking through all recent commits manually, I used bisect. Bisect is not a magic bullet, and you could do the same manually, but it’s a good tool in the toolbox to know sometimes.

Yes, many times. And I recall using the technique manually back when I was working with Subversion many, many years ago. No fun stories though, sorry, it’s just another tool in a toolbox.

For those (like me) who were not aware of git bisect:

The git bisect command is a powerful tool that quickly checks out a commit halfway between a known good state and a known bad state and then asks you to identify the commit as either good or bad. Then it repeats until you find the exact commit where the code in question was first introduced.

If you know about bisect and don’t find it useful, my first guess is you aren’t making enough commits (or you’re squashing too many of them). Keep your git history granular, make intermediary commits when possible (as long as the intermediary step doesn’t make it completely broken), and you’ll be using bisect for a good chunk of regressions.

I certainly have! Although I can count on two hands how many times I’ve used it, it has proven to be extremely powerful when trying to pin-point changes that introduced non-trivial bugs. Specifically if the time-span of when the bug was introduced it is very useful to quickly sift through commit history.

Yeah, I don’t need it often but the sort of problem it solves is very hard to solve otherwise. It is useful for when you know something is wrong and you have an easy way to check if the problem is there but when you don’t know what the actual cause of the problem is.

The most obvious usage is for checking if the build passes. This is something easy to do with tools but hard to know why (or when) it began to fail.

It’s mostly relevant for a project you’re not familiar with (perhaps it is/was someone else’s project, or perhaps a project that’s too large for a single user to be familiar with the entirety of), since it helps you figure out where a bug came from.

If you’re familiar with the entire project you usually don’t need it IME.

Yeah it’s saved my bacon a bunch of times

No, but I once wrote my one git bisect without realizing git bisect existed.

I used it to track down a commit that caused an old bug. The commit didn’t pop out on a cursory check, and I was getting lost in tracking the test results.