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

More...