If you're handy with shell scripts, you can do:

  git bisect run my_script

my_script should return 1 if tests failed, or 0 if they passed. Git will then go off and find the commit that broke things.

That's pretty cool; I always wondered how to use git bisect.

2 years in to using Git and I'm still learning workflow stepchanges every week.

Scott Chacon touched on this in his SOR talk I think. There will be a vid up for it soon I think.

If anyone needs to bisect an intermittent bug, I have written a bayesian version of git bisect. It can be found at: http://github.com/Ealdwulf/bbchop/tree/master

I can personally vouch for the awesomeness of 'git bisect', especially when combined with 'git rebase' to reconstruct trees minus troublesome commits.

Like many tools, I think git bisect's advantage comes from reducing the amount of thinking that you need to do to accomplish a task. Before git bisect I'd often stare at pieces of broken code or poke around in a debugger for hours on end. Now, ~1 hr or so with git bisect and friends, and the job is done...and I get to spend brain cycles thinking about something else.

The coolest part of git bisect is the run option: http://tlrobinson.net/blog/2008/10/01/git-bisect-run/

If you can write a shell script that returns 0 when the test passes and 1 when it doesn't, git bisect run will do the tedious part for you.

My brain just gitsploded. More like this, please.