Where'd that fail come from and how do I find it? -- git bisect
| Code | intermediate |
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](mailto:JRiley@JRILEY) /c/Projects/Core ((someMiddleHash...)|BISECTING)
What git will do is say ok, somewhere between HEAD and
$ 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](mailto: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](mailto: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.