We’re slowly gearing up for another release of Bodega at the office. I’ve been sending builds to some people to have them start testing things for us, and hopefully catch things that our normal testing process hadn’t caught. Basically every tester returned the same complaint: “The stuff in the Featured section isn’t centering correctly.” Oh… well that makes sense, I changed how stuff in a couple crucial nib files work, and it’s quite possible, if not probable, that they have auto-saved settings in their pref files that’s conflicting with new rules. But then I got reports from them saying it was happening even with clean prefs.
Uh-oh. When did this break? That’s when my mind goes into this awesome scan of memory, recalling all the times that I did work that might have possibly, somehow, affected this. I came up with a couple incidents, and those few times I was just playing around with nib files (files that let us lay out interfaces, for the non-coders). I did what I typically do, I ran “git log ThatFile.xib” to see when I had been playing around in there. I went back and checked a bunch of those commits, and could figure out what I would have changed to break this. I had a few ideas, but nothing concrete.
I spent the next 3+ hours in Interface Builder just trying to re-lay things out to work. Believe it or not, it was a pain in the ass to get those ads and other content in the Featured screen of Bodega to keep centered without using any code (I refuse to use code for that type of simple layout stuff). It shouldn’t be a pain, but it was. I painstakingly recreated a bunch of it, following all of my tips that I’ve left for myself for how to do it. No dice. Rick’s Enraged.
Something wasn’t making sense. This bug must be somewhere else, but I don’t know where. What else could it POSSIBLY be? That’s about when I recalled reading about “git-bisect” in the Git manual. I remembered thinking “well that’s neat.. but when do you ever really not know when a bug crept in?” Well… now. That’s when.
Git-bisect is a command that’s a part of git that helps you identify when a bug crept into your project. It’s rather simple, but by god, is it cool. You tell it “I’m in a bad state.” , and then tell it when it was that you know you were in a “good state.” Well.. I’m sure I’d not have let 0.9.6 of Bodega go out with a bug like that. So I told it that was my last known good state. It’ll then use something akin to a binary-search, and pick a mid-way point. It’ll put your code in that state, and then you can test it. Is it good? Is it not? You tell it yay or nay, and then it picks another mid-way point. Rinse, lather, repeat. As any computer scientist can tell you, a binary-search is an insanely fast way to go through a lot of possibilities. About 6 checks in, it had narrowed it down to one commit and showed me the log of it. ”What? That’s freaking impossible.” I found the commits before and after, and tested. Sure enough, before the bug wasn’t there. And after it was.
That commit had a single line of code changed. The code had SOME relation to the Featured screen, but only in a distant way. But at least now I knew what was causing this change in behavior. It took me another hour of debugging to figure out why changing that one line affected the layout. (answer: cramming a screen worth of controls into a 50x50 view then resizing to the proper size hurts autoresizing constraints. big time.).
Without git-bisect, I don’t know how I’d have found this bug. I’d likely have to have manually started doing mid-way point testing which is time consuming when you have a large number of commits. It’s great to know that there’s a tool out there to help me isolate the change that’s causing a bug. It’s not perfect, but it’ll definitely become a part of my developer tool box.