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?
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.
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.
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.
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.
That’s a problem I’ve seen as well. It seems like your instance needs to be federated with the commenters instance, even if they are posting to one you’ve already federated.
The few times I have used git bisect, it has been on projects with no automated tests where the reported issue last worked far in the past. It isn’t my first option, but it is what I turn to if I can’t figure out what the correct internal state for some portion of what triggers the issue is supposed to be, saving a lot of time I could have spent banging my head into a wall.
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.
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.
Usually when theres a “mystery” bug on something that already worked before. Spending half a day running the build script over and over again, is still faster than debugging in different parts of the codebase with the hope of finding some hint.
Quite a few times, sure. git bisect is a specific case of a more general technique – binary search fault localization – which comes in handy every once in a while (you can go a long while without needing it, but when you do need it, you’ll be thankful for it). If you can’t otherwise trace where in the code something is going wrong, bisect the code: comment or remove half of it out, see if it reproduces (therefore localizing it to either the removed or the remaining half), and repeat. If you’re working with some software that’s breaking on your config after a major version bump, bisect your config. Don’t have an idea what introduced a bug into your branch? git bisect.
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.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
For those (like me) who were not aware of
git bisect:The
git bisectcommand 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.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.
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.
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.
That’s a problem I’ve seen as well. It seems like your instance needs to be federated with the commenters instance, even if they are posting to one you’ve already federated.
Looks to me as though it’s just beehaw users. As far as I’m aware they recently decided to defederate.
Hadn’t thought of this one, but yeah, that explains it.
I used it a few times to find a bug, introduced some commit ago.
The few times I have used
git bisect, it has been on projects with no automated tests where the reported issue last worked far in the past. It isn’t my first option, but it is what I turn to if I can’t figure out what the correct internal state for some portion of what triggers the issue is supposed to be, saving a lot of time I could have spent banging my head into a wall.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.
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.
Usually when theres a “mystery” bug on something that already worked before. Spending half a day running the build script over and over again, is still faster than debugging in different parts of the codebase with the hope of finding some hint.
Quite a few times, sure.
git bisectis a specific case of a more general technique – binary search fault localization – which comes in handy every once in a while (you can go a long while without needing it, but when you do need it, you’ll be thankful for it). If you can’t otherwise trace where in the code something is going wrong, bisect the code: comment or remove half of it out, see if it reproduces (therefore localizing it to either the removed or the remaining half), and repeat. If you’re working with some software that’s breaking on your config after a major version bump, bisect your config. Don’t have an idea what introduced a bug into your branch?git bisect.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.
Yeah it’s saved my bacon a bunch of times
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.
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.