In this series, I cover a lot of magical tools and git bisect is probably the best example of such magic. The hardest part in debugging is knowing the general area of the bug, bisect literally shines a light on the specific commit that caused it! Before we begin, let’s make one thing clear: bisect is a tool for debugging regressions. It does nothing for regular bugs. When we have a regression, we typically know that the issue used to work in a specific release, we would typically have a specific revision where the code worked. We would typically know that it doesn’t work in the current version, but which commit along the way causes the failure? In the Olden Days Back in the old days of SVN (or CVS, SourceSafe, etc.) we used to checkout an older version of the repository and test on it. If it failed, we’d go further back and if it succeeded we’d go forward to hone in on the specific commit that failed. Those among us who were lucky enough to work with competent QA departments could often pass this task to them. Ultimately, the work was manual. When zeroing in on the issue we’d follow the sensible search strategy of dividing the number of revisions in half and going to the middle of the set instead of going one step at a time. This significantly shortened the time spent looking for the problematic revision. However, there are still many revisions to search through. At this point you might wonder, why didn’t you automate these things? We sometimes did but since no versioning system was as dominant as git these automations didn’t last and I’m not aware of such automation that made it into any version control system. But git bisect made it in and is the automation of this heuristic. Git Bisect: Find the Bug. Automatically! That’s right. It does exactly that. The simplest use of git bisect starts with the command: git bisect start This switches us into bisect mode. We can now define the “good” version where things used to work properly. E.g. for I can use the revision as the good revision. We can thus mark it using the command: https://github.com/codenameone/CodenameOne/ 79a8e37adb7dd48093779bd3657142e607bdd2d9 git bisect good 79a8e37adb7dd48093779bd3657142e607bdd2d9 Once we do, we can activate bisect traversal by marking the bad revision. For most cases this means the current head revision which is the default, but you can specify a specific revision as an argument to this command: git bisect bad Once this is done, we can move between revisions by redefining the good or bad revisions. Here we ran these commands on the Codename One repo and got this output: Notice the value at the bottom. This is the current revision we “jumped” to. We can now mark this revision as good or bad based on our manual testing. 68dabb4f70c8295887d2da5c466dbe89fc910408 I marked it as bad, could have marked it as “good” and that would have worked fine. This moved bisect to the next revision we need to test: This Sucks! Or Does It? Going through every revision manually is a major pain! Sure, it’s better than randomly looking through revision logs and jumping through revisions while keeping our place in our head. But just barely better. Luckily, there’s a better way: . run Bisect can run an arbitrary command for us on every revision it encounters. If the command returns zero (as a process exit code) the revision is good. If it returns something else, it’s bad. This way the broken revision will be identified automatically for us with no human interaction. Normally this works great for a shell command but as a Java developer this is a bit of a pain. Typically, I would have a unit test that shows the failure. Unfortunately, that unit test doesn’t exist in the older version of the project. Then I also need to compile the project for this to work. So while git bisect seems cool with the run command, how do we use it for a compiled language like Java? This is actually pretty easy. We can create a complex command line but personally I prefer something like: git bisect run testMyJavaProject.sh Then I implement the shell script with the commands that build/test. But before that I need to create a unit test that fails for that specific bug. I assume this is something most of us can accomplish easily. Now that we have a unit test creating the shell script is trivial. The code below assumes you use maven for building: #!/bin/sh

mvn clean
mvn package -DskipTests
mvn test -Dtest=MyTestClass That’s it. Notice that if compilation will fail because of dependencies within the test class you might end up with the wrong revision. So keep the test simple! When you’re done with git bisect or wish to stop for any reason just issue the command: git bisect reset TL;DR Git bisect is probably the simplest tool I will cover in this series. But it’s also one of the most important tools. Learning to use it effectively can save you days of tedious work and hunting around for an issue. Despite these huge benefits, it’s a relatively obscure feature. The reason for this is that for 98% of the time we don’t need it. But in that 2%, we REALLY need it… Hopefully, the next time you run into a regression you’ll remember that it’s there and use this post to hunt down the issue. Also Published Here

Keep

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

Git Bisect for Understanding the Root Cause of Regressions

Git Bisect for Understanding the Root Cause of Regressions

Too Long; Didn't Read

Company Mentioned

Shai Almog

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Git Bisect for Understanding the Root Cause of Regressions

Too Long; Didn't Read

Company Mentioned

Shai Almog

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES