Git tip: use bisect to find regression bugs quickly

Hi Everybody,

I was reading the Git User Manual this weekend and found this handy tip
and thought I would share it with you guys. I already used this with
great success in finding a regression bug in my own code.

If you are using the Git repository of Lazarus (mirror of the SubVersion
repository) or you have some other Git repository, then you can let git
help you find regression errors.

This is how it works...

Suppose version 2.6.18 of your project worked, but the version at
"master" (trunk in SubVersion terms) doesn't. Sometimes the best way to
find the cause of such a regression is to perform a brute-force search
through the project's history to find the particular commit that caused
the problem. The 'git bisect' command can help you do this.

It follows the same principal as outlined in the Lazarus wiki (url shown
below), but seeing that you have the full repository history local,
things go much quicker.

http://wiki.lazarus.freepascal.org/How_To_Help_Developing_Lazarus#Dealing_with_regressions

So here is how you do this with git:

$ git bisect start
$ git bisect good v2.6.18
$ git bisect bad master
Bisecting: 3537 revisions left to test after this
[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage
depend on SCSI rather than selecting it [try #6]

You tell git that master (trunk) is bad - it has the regression bug. And
the last known good version was v2.6.18. Git now checks out a revision
between master (trunk) and v2.6.18. Compile and test it, and see whether
the regression bug is there. Lets assume the bug is still there. Then:

$ git bisect bad
Bisecting: 1769 revisions left to test after this
[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless
bitmaskings

This tells git that the revision it checked out earlier is still bad, so
it means the regression was even earlier in the project history.
Continue like this, telling git at each stage whether the version it
gives you is good or bad, and notice that the number of revisions left
to test is cut approximately in half each time.

Once you found the revision containing the regression bug, make a note
of the revision number and then run the following command to take you
back to master (trunk) so you can fix the issue.

$ git bisect reset

The truly awesome thing is that if you can test if the problem is good
or bad without human intervention, you can automate the whole bisecting
process. For example, say the bug is an incorrect value returned from
some function. You can write a quick testcase which returns good are bad
if the test was run. Git can then use that testcase and automate the
bisecting and within seconds you will know the exact revision that
caused the problem. 

I already found this automated bisecting very useful in finding a
regression bug in my own project. So I thought other git users might
find this tip useful as well. For more information on the bisect
command, run:  git help bisect

Regards,
  - Graeme -

_______________________________________________________
fpGUI - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/

--
_______________________________________________
Lazarus mailing list
Lazarus <at> lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus