I’d heard git bisect was a fun thing to play with, and after having an opportunity to play with it last week, I have to agree!

I’ve been tracking edge rails as a submodule on a current project. It’d been a couple weeks since I last updated rails and after a friend told me they fixed a bug with using :having in a named scope I decided to sync up and refactor some code. This is usually an uneventful operation.

1 2 3

cd vendor/rails git checkout master git pull

Run my specs and make sure everything appears to be ok.. and commit the update. Only, this time I experienced about a dozen failing specs following the update. I wanted to quickly find out why the specs were suddenly failing and there were a couple dozen commits I had pulled in. So I used git bisect to figure it out. Since my specs were passing before the update, I use the SHA I was tracking before, 92a30b0, as a good reference point.

1 2 3 4 5 6

# still in the vendor/rails dir, and my specs are failing git bisect start # tell git, the current state is bad git bisect bad # tell git, when the state was good git bisect good 92a30b0

git then finds a commit between the known good and bad, and I re-run my specs. If the specs fail, I tell git bisect it’s bad, if the specs pass, I tell git bisect good. Either way, it grabs another commit and I repeat the process until we’ve narrowed down the exact commit that causes the specs to fail. Awesome. You can save yourself the manual labor of telling git if it’s good or bad by telling git to run a script/command

1	git bisect run ~/test.sh

where test.sh runs the test/spec suite and returns good (0) / bad (>0) error codes

git help bisect for fun and profit