My response was mostly tongue in cheek. But I'm curious... where do you work that required code reviews before every commit? Seems like an awful lot of bureaucracy. For my projects I usually set up post-commit code review systems.
I'm at a startup now. But I think you'll find most of the big shops you know about, like Google and MS, generally practice pre-commit review.
Open source projects often will do post-commit review. The review process is viewed as friction, and they don't want to block contributors due to the review process.
I personally prefer pre-commit review, although post-commit is a legitimate option (one I admittedly wasn't thinking about at the time).
So where do developers checkpoint their work until the official commit?
Either:
The smarter ones have to maintain a second source control archive (unless they are allowed to make personal branches, in which case the "public commit" is really just a merge, and probably a good thing),
or
the dumber ones just work without a net, loosing changes, and/or having to manually back out edit and test sessions that didn't go as well as hoped.
Oh, and I just realized I'm replying to the same guy about this.
Early, and often, that's how. Surely you don't forbid a dev from saving his/her work (where it's backed up) and keeping a stream of "undo" checkpoints in the repository until only after somebody else had a chance to look it over???
Now, it does make sense to have a review before merging a development branch to a release candidate, but not to block check-ins/commits in general.
OK, so I've known senior staff who did want to have just this sort of restriction, and I found it foolhardy then, as well.
Second, to fix the typo, fix it in one place, and click->"rename" and it renames it everywhere else.
Last, if your IDE has spellchecking support, it will let you know that part of your name does not exist in the dictionary.