[Digikam-devel] "git bisect run" - the lazy way of fixing bugs

Andi Clemens andi.clemens at gmx.net
Mon Oct 26 08:35:51 GMT 2009


Hi,

for those of you that use git, here is a neat way to find and fix regression 
bugs that you might not know.

Regression bugs are nasty and annoying, especially for users. Bugs that have 
been fixed months ago and re-appear, really make a bad impression.
But actually regression bugs are easy to avoid, if we would have a good test 
suite (unfortunately, we don't ;-)).

Anyway, finding bugs that are not easy to track down is fun with "git bisect". 
But it is even more fun when using "git bisect run", the _lazy_ way of finding 
bugs.

In the past I had to fix a bug in the AdvancedRename utility. Since I wrote 
tests for the utility, it was very easy to track down a regression bug by 
telling git to bisect automatically, using a script.
This script needs to return 0 in case of a success (no regression error), or 
any number from 1 up to 127, excluding 125.
125 is used to tell "git bisect" to skip a commit, in case of an compile error 
or any other issue you might have.

So I set a start and end point for "git bisect", wrote a little script that 
looked like this:

---------------------------------------
#!/bin/bash
make -j4 || exit 125
./tests/advancedrenametest
---------------------------------------

and started git with "git bisect run ./thescript".
That's it. Now you can go to bed or whatever you like to do, and when you 
return, git tells you that user xxx and commit #yyy are responsible for the 
bug, so you can immediately write a hate-mail to him (let's just assume it is 
NOT you ;-)).

Hope this little tip will encourage you to write some more unit tests and 
finally switch to git,, using SVN is just a pain, am I right, Marcel?

Andi



More information about the Digikam-devel mailing list