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/

This is how it works with SVN:
http://wiki.lazarus.freepascal.org/How_To_Help_Developing_Lazarus#Dealing_with_regressions

An example script to automate it:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/scripts/florian/unix/searchrev?view=markup&revision=574&root=fpcbuild

Vincent

Vincent Snijders wrote

This is how it works with SVN: http://wiki.lazarus.freepascal.org/How_To_Help_Developing_Lazarus#Dealing_with_regressions

Yup, the same link I referenced in my first posting.

An example script to automate it:

That's only for unix users, but a good starting point none the less. Maybe this should be mentioned in the above URL as well, otherwise nobody will know about it except you and Florian. I will update the wiki shortly...

What should also be mentioned to users wanting to use such an automated regression script with SubVersion, is that you better have a fast internet connection and lots of bandwidth. Using that script with my unreliable 3G connection and limited bandwidth, it's just not feasible. The main advantage with Git (and probably Mercurial too) is that the whole repository history is already on you computer (local), so checkouts are instant and can be done while offline.

Regards,
- Graeme -

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

"The main advantage with Git "

Why is that an advantage? I mean, it may be an advantage for some people, but the way way you generalize it, it sounds that would be an advantage for everyone? I much prefer to have the repository on the server.

And if I understand this correct, then GIT downloads *every* intermediate version to your PC, every time you upgrade (otherwise, how can they already be there). That to me would be a disadvantage, I may never need that data.

Regards
Martin

Martin Friebe wrote

people, but the way way you generalize it, it sounds that would be an advantage for everyone? I much prefer to have the repository on the server.

I'm not starting this again.... :-)

And if I understand this correct, then GIT downloads *every* intermediate version to your PC, every time you upgrade (otherwise, how can they already be there). That to me would be a disadvantage, I may never need that data.

Read the "Git Mirrors" page on the Lazarus wiki:

http://wiki.lazarus.freepascal.org/git_mirrors

To quote myself....(which is never a good thing)

"$ git clone git://github.com/graemeg/lazarus.git

...this will download 57MB of data and unpack to around 144MB on your hard drive. This has the _whole_ history of Lazarus. A checkout via SubVersion of only the trunk revision is over 320MB - more than double what Git is with full history."

Even though you end up with every revision, Git's compression is clearly *much* better than SubVersion's. The WHOLE history of Lazarus is a 57MB download (and unpacks to 144MB on the hard drive). Compare that to a SINGLE trunk revision using SubVersion which equals to around 320MB. The Git repository is much smaller, no matter how you get more bang for you buck! ;-)

Disclaimer:
-----------
These values were accurate at the time I created the wiki page. Values may have increased since - as the project grew.

Regards,
- Graeme -

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

"The main advantage with Git (and probably Mercurial too)..."

Hey, at least this time I mentioned Mercurial as well... ;-)

Regards,
- Graeme -

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

very sad... :)

....

So it eats more CPU to do the work?

Anyway it doesn't matter, It was for the arguments sake only.

Best Regards
Martin

Martin Friebe wrote

> I'm not starting this again.... :-) very sad... :)

I learned from my mistakes - and when to bite my tongue. :-)

Regards,
- Graeme -

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