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?
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.
This is how I used it too. Write a test that fails with the “bad” version. Use a script to cherry-pick and run the test. It’s fun to watch it find the first bad commit even though what git bisect does is quite simple.
This exactly. The more developers working on different parts of an application, the more chance of an apparently-easy merge having unforeseen side effects. git bisect is the easiest way to narrow down the problem so real debugging can begin.
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@beehaw.org
All things programming and coding related. Subcommunity of Technology.
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.
This is how I used it too. Write a test that fails with the “bad” version. Use a script to cherry-pick and run the test. It’s fun to watch it find the first bad commit even though what
git bisectdoes is quite simple.This exactly. The more developers working on different parts of an application, the more chance of an apparently-easy merge having unforeseen side effects.
git bisectis the easiest way to narrow down the problem so real debugging can begin.