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?

  • aksdb@feddit.deEnglish
    9·
    1 year ago

    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.

    • ffmike@beehaw.orgEnglish
      3·
      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.

    • canpolat@programming.devOPEnglish
      3·
      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.