Programming

13373 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

alyaza@beehaw.org

Hexorg@beehaw.org

remington@beehaw.org

Have you ever used git bisect? (programming.dev)

submitted 1 year ago by canpolat@programming.dev to c/programming@beehaw.org

19 comments fedilink hide all child comments

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?

you are viewing a single comment's thread
view the rest of the comments

[–] aksdb@feddit.de 9 points 1 year ago* (last edited 1 year ago) (2 children)

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.

[–] canpolat@programming.dev 3 points 1 year ago

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.

[–] ffmike@beehaw.org 3 points 1 year ago

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.