Git bisect is the hero of the week! It turned out that some time between now and three weeks ago, the login functionality broke in the Rails app we’re developing. It didn’t break completely, of course, just in certain environments. And looking at the logs, I had no idea what the error could be, so I just had to work it out from the diff between the last working commit and next. Well, between three developers, there can be quite a few commits during three weeks and with a lesser version control system I would have had to

1. checkout the previous revision,
2. restart the server (because plugins, gems and even Rails can change between versions),
3. try to log in,
4. see if works and stop if it does,
5. repeat from 1.

With git, I can ask git itself to perform a binary search among all the revisions between now and three weeks ago. It would go like this:

1. git bisect start HEAD 57c3aaa,
2. restart the server,
3. try to log in,
4. see it fail or succeed,
5. say git bisect bad or git bisect good to make Git checkout the next node in the binary search tree
6. repeat from 1 until Git says that it found the culprit.

It doesn’t look a lot better, but it is if you have 300 commits. Of course there is nothing to stop you from doing a manual binary search with Subversion, or even to step back one day at a time to narrow it down, and we didn’t actually have 300 commits. But where Git really shines is in the fact that if I can write a program that can tell if a version is good or bad, all I have to do is

1. git bisect start HEAD 57c3aaa,
2. git run ../my-test-probe.rb

and sit back and wait. Provided of course that the program also knew how to start and stop the server. Well, here is that program, for your debugging pleasure, and mine: