Yesterday while mucking around with the open map Popcorn plug-in, I came across a rather interesting bug. This bug caused Popcorn to get confused about the out times of plug-ins, causing them to hide and display at odd times.
I noticed the odd behaviour by chance while rewriting the open map plug-in. In our Popcorn Repository on github in the "plugins/openmap" directory, we have a demo html file that I was using to check if the maps were working as expected. Thanks to their layout with one another, it soon became clear that no matter what I set the "out" value to, things did not disappear as expected. I decided to test if it was my changes to open maps, or if it was something deeper. After setting up a reduced test case that uses the simplest plug-in of all (footnote), it was clear that there was an issue in Popcorns core.
The big question then was "How in the heck are we going to find this bug???". Then, from across the room, Jon Buckley did appear! Jon said this issue was a job for git bisect. Git bisect is a really handy tool for isolating the exact commit where bug originated from.
To use bisect, you must have a standalone test that is untracked by git, while still using the resources in the repository. For the purposes of my case, I used the above reduced test case. To begin bisecting, you type:
git bisect start
Then switch branches/tags ( git branch [branchOrTagName] ) until you find a point in the code where the test case works as expected (doesn't matter how far back you go as long as it works). in my case this was Popcorn v0.4. The next step is to run:
git bisect good
which marks this commit as the point in which we know the test passed. Then switch to the branch/commit where you noticed the bug, and test to confirm it is present. If it is, run the command:
git bisect bad
After this, you should see bisect output something like:
Bisecting: 200 revisions left to test after this (roughly 8 steps)
[b70c7fcd3634eb1a33e6fdc36b463045433b86d7] Merge remote branch 'scott/style' into 0.6
At this point you run your test case to determine if the commit that bisect has checked out passes or fails the test case. If the test passes you run
git bisect good
and if it fails:
git bisect bad
which will cause it to switch to another commit and wait for you to test again. As you continue testing, bisect will narrow things down until it pinpoints the EXACT commit that broke the code. Best of all it tells you WHO did it! Here's what git bisect told me about the bug I found:
commit 79a7b4d1c337e06a8c0a61371e0fcf84beeec1c9
Author: ScottDowne
Date: Wed May 11 13:33:40 2011 -0400
[#t483] performance work for addTrackEvent
:100644 100644 0e4debd959e34f4d09536989e57fb98ea19b7178 4d1473a49467e99a9657d6fc4a0ef3cbdeca5f3d M popcorn.js
Busted!!!! I filed a bug on this and let Scott know, and by the end of the day we had a patch staged.
Thanks, bisect!