No, that would be the commit following :)

I really don't like having the (small) fix in the same commit as the commit that adds a number of tests to verify the fix. Note that the OP is dealing with a project that does not have tests (yet).

In a project where you do test-driven development, I would completely agree with you.

heh. My comment was more about the "compiling is unit testing" philosophy. Plus I've become a bit of a TDD crack monkey.

Though it reminds me of something that's come up for me a few times. I've lately been finding myself wanting to have a local subordinate source control repository (more like a sub-branch.) That way intermediate nonfunctional code versions would be checked in at save time, but not committed to the real branch.

I'm not at all convinced it's not a wrongheaded thought. But I'm frequently finding myself wanting to roll back micro-changes that weren't solid enough to check in to the primary SCM system.

Me