April 2010 Archives

git bisect mini tutorial

Using git bisect to track down bugs

Something in your application worked a few days ago, and now it doesn’t. Aararrgh! We’ve all been there. Nobody has any idea which change broke it. You use git log -p to thrawl through the recent changes, but nothing stands out. What to do, what to do? Use git bisect to minimize or completely automate finding the commit that broke it!

Run git bisect start to begin. Since the current version is bad, you run git bisect bad to let git know.

Now you need to tell it which commit/version is the latest “good one” - often that’d be the last released tag, so for example git bisect good v25.0.3.

git will now decide on a commit you should test, check it out and tell you how many are left.

If you are just testing manually, you’ll now manually run your tests and tell git if it’s good or bad. In our web environment that’d often involve restarting the application (just to make sure) and then running the tests.

When you know if this revision has the bug or not, you run git bisect bad if it’s bad and git bisect good if things are good and after a little while of that git will tell you which commit introduced the bug!

If you can do the ‘is it good or bad’ test automatically, you can run ‘git bisect run command’ (where command is make, prove t/sometest.t or a custom shell script) and git will figure it out automatically while you get coffee or go to lunch!

About this Archive

This page is an archive of entries from April 2010 listed from newest to oldest.

August 2009 is the previous archive.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 4.36
/* bf */