Where'd that fail come from and how do I find it? -- git bisect

Earlier this week I found myself in an interesting spot.  We had a hell of a bug come though that had no real reason for existing, much less any kind of answer to "how did this even get there?!".  Someone mentioned I should use git bisect -- I'd never heard of this.  It's a little strange at first, but once I got the hang of it, it's really slick.

Say for instance your on your repository on the latest and greatest and you find a bug was introduced ... say ... three weeks ago.  You don't know when exactly, but you know it was sometime in that time frame.  Grab a hash code, (treeish, the first few letters of the hash I'm told are usually enough for uniqueness) and go ... something like this ...

git bisect start HEAD <someHash>

and you'll see something like this ...

$ git bisect start HEAD <someHash>
Bisecting: 174 revisions left to test after this (roughly 8 steps)
[someMiddleHash] Comment for that commit

JRiley@JRILEY /c/Projects/Core ((someMiddleHash...)|BISECTING)

What git will do is say ok, somewhere between HEAD and <someHash> was a screw up, so it will pick the middle commit and give that as a starting point.  Build, do your dance and determine if its a good (problem isn't there) or bad (problem still exists) as such ... in my case, I'll say its bad.

$ git bisect bad
Bisecting: 86 revisions left to test after this (roughly 7 steps)
[yet another hash] comment for that commit

Note the revisions are cut in half and there's "roughly 7 steps".  This means I'm probably 7 steps away from finding the commit that messed up my stuff.  Ideally, you'll do your dance of building or whatever to test if that commit shows the problem or not (hint: script this) and you'll indicate good or bad depending on well, if it's a good build or bad. When you get near zero revisions and zero steps, it'll do something like the following...

JRiley@JRILEY /c/Projects/Core ((somehash...)|BISECTING)
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[someHash] a very suspicious check in comment that talks to your problem

JRiley@JRILEY /c/Projects/Core ((somehash...)|BISECTING)
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[someHash] the checkin just before the failure

 When you're done, you can look up the hash for the checkin, see what code has changed, etc etc etc.  When you're all done, a simple git bisect reset will get you home and back to where you started.  I have to admit, I'm a huge fan.

Comments are closed