[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