this post was submitted on 25 Jun 2023
26 points (100.0% liked)
Programming
13362 readers
1 users here now
All things programming and coding related. Subcommunity of Technology.
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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 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.