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?
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?
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.