[Neurodebian-upstream] Expressing my gratitude to Linus T. for git

[Yaroslav Halchenko]

Dear subscribers of the list,

I am sorry for using this mailing list for a somewhat childish expression of my
feelings, but I do sincerely love GIT and want to share this feeling with
you ;)

You can find various comparisons, debates, and flamewars comparing existing
DVCS solutions... Myself, recently I have started to get acquainted with HG as
another viable alternative.  But after all, I just feel more comfortable with
GIT since it is actually quite simple, despite UI being somewhat not very
friendly and over-featured at times.  And today, once again, GIT has
shown its value indispensable value.

Today, in the course of the development of PyMVPA we have ran into a
"new" issue -- libsvm bindings started to spit out a list of quite nasty
exceptions upon exit:

Exception TypeError: "'NoneType' object is not callable" in <bound method SVMModel.__del__ of ...

Interestingly this issue actually existed for a while but was not spotted
before (exit code is not altered by this, so daily tests did not raise any
concern) and thus is not related to the most recent developments.  To
troubleshoot the issue I have decided first to find out when this issue
was introduced, thus I have decided to use a nice tool from GIT:

git bisect

I have found some elderly state of PyMVPA from Feb 2010, which allowed to
build PyMVPA against libsvm 2.90 and where unittests did not cause the above
exceptions.  Then I prepared a little helper script:

$> cat trash/bisect-libsvm-nontype.sh                   
#!/bin/bash
 
{ make clean; make ;} > /dev/null; nosetests -s mvpa/tests/test_svm.py 2>&1 | { grep 'Exception TypeError' && exit 1 || :; }

which builds pymvpa, runs the test which shows the signs and grep for the
output (since, as I have mentioned before, exit code was not altered by
the above exceptions).

Then I simply ran the bisect:

git bisect start maint/0.5 d30d28b112b7f0ba4cb09a4e01a14b47e7218382
git bisect run trash/bisect-libsvm-nontype.sh

and went to drink tea, since it is 723 commits between good state (d30d28b1)
and current HEAD of maint/0.5.  But since bisect does a binary search, it
took just  2 minutes on the laptop, and checked 11 commits to converge to
the commit which introduced the regression:

 beba4ed868c0e86ffda79786f01a59734ef9aa1b is the first bad commit

As the result -- I know now which commit has introduced this regression, and
that gives me a better sense now of what went wrong.  And everything is solely
due to the great powers of GIT.

If you have never tried GIT before, I would advise you to give it a try.

If you like to get some informal introduction into ideas behind GIT
fundamentals, I would highly recommend

Git foundations, from Matthew Brett
http://matthew-brett.github.com/pydagogue/foundation.html

Cheers,
-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/neurodebian-upstream/attachments/20101018/3c792f99/attachment.pgp>