Saturday, February 16, 2013

now which change caused that infinite loop?

Today I volunteered to do a pep8 clean-up on one of the projects I'm working on. I committed the changes and was about to push them up to GitHub when I realized I hadn't run the tests. So I ran the tests and something threw a "RuntimeError: maximum recursion depth exceeded..." exception. Well crap. I only touched just about every file in the project.

After checking to see if I had changed any files mentioned in the stack trace (nope), or parent classes of any classes mentioned (yes, two 'two spaces before inline comment'), I started looking for other options.

I know that git has the 'bisect' command to do a binary search on commits, but I committed all of the files at the same time, and I've never heard of a facility to do a binary search on changed files...really, changes like pep8, that are not supposed to affect functionality and are not inter-related, would be the only use of it.

So here's the process I'm following:

If the tests fail:

  1. un-commit the changes (git reset HEAD^)
  2. stage half of the changes and check them in
  3. stash the other half of the changes
  4. run the tests
If the tests pass, 
  1. un-stash the stashed changes
  2. stage and commit half of them
  3. re-stash the other half
  4. run the tests
Repeat.

After two cycles of this, I did what I should have done in the first place - run test on master, at which point I discovered that the failing tests were an unintended consequence of some logging I had added to one of the project's dependencies. Not my most brilliant moment, but at least now I know what I will do  if I run into a similar problem.