Had a client email me recently, mildly concerned, as an update to WP eCommerce broken his search layout. I told him that I couldn’t think of anything between the latest version and the prior version that would have caused any such thing, but I’d be more than happy to check it out.
Initially, if I’m being quite honest, I just assumed it was user error. It’s easy to mis-configure things, set up a theme wrong, etc. Any number of things can go wrong. But, I dug in and in fact, we had broken it. I didn’t recall any changes in the 913 commits between the two changes.
With nothing obvious, and 913 commits between release – what was a developer to do? Enter, git bisect.
Git bisect is amazing. Prior to using it, you might think to yourself,
“Hmm, self, I suppose I can checkout a few different commits, figure out a commit where it works, and one where it doesn’t, and sort of narrow down a range until I find it.”
And that would be a really good thought. But it would take you, a human, waaaaaaay longer than git would take. That very thought you had? That’s what git bisect does. Imagine you have the master branch, latest commit checked out. You know that a previous version branch worked fine. Check this out.
git bisect start git bisect good git bisect bad branch-3.8.14.4
And boom, you’ve started down the path. Git will analyze how many revisions exist between good and bad, split the difference, and checkout that commit. Then, test to see if the bug still exists. If it does, git bisect bad. If not, git bisect good. It will keep narrowing down the commits until it finds the precise commit that caused the issue.
In case you remain unconvinced – remember – I was able to wade through 913 commits to find the single commit that caused a bug in a piece of software that spans hundreds of files and over 150,000 lines of code.
It took about three minutes.
Git bisect is amazing.
`git bisect` also has the possibility to run a script and check its exit code to understand if the given revision is good or bad.
This might not be useful for the bug you were looking for (because I guess that creating such a script would be way more complex than just looking at your browser window) but for other projects writing this test script might be easier (e.g. if you’re building a command line tool).
From the man page:
> Bisect run
> If you have a script that can tell if the current source code is good
> or bad, you can bisect by issuing the command:
>
> $ git bisect run my_script arguments
> Note that the script (my_script in the above example) should exit with
> code 0 if the current source code is good, and exit with a code between
> 1 and 127 (inclusive), except 125, if the current source code is bad.
Great point, Alessandro! Thanks for sharing.
Great article Justin! You are a stud! Many people I talk to seem nervous about using git bisect but after they are shown how easy it is to use wind up making it one of their primary tools in debugging. I know personally it has helped eliminate hours of bug searching in several large projects. Great to see more people promoting it!