this post was submitted on 25 Jun 2023
26 points (100.0% liked)
Programming
13386 readers
141 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 2 years 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 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.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.