1) Sometimes (usually the worst times) you just need to check something in, maybe it doesn't pass pep8 but when service is down nobody gives a shit.
2) Instead of promoting thinking and caution it promotes attitude of "hey check it in and see if it sticks".
Post commit hooks that report broken tests, poor code, etc preferable to whole team are far superior. After first couple of times being shamed people will actually look over their code, run tests, run pep8, etc to verify the commit isn't bogus.
It seems like pre-commit hooks are an excellent solution, based on your reasons.
First, they're easy to skip with one flag. (But do you really want to be skipping tests when things are already broken? Assuming pre-commit hooks don't take many minutes to run – if they do, I'd consider those hooks too long for a pre-commit – it seems wise to sanity check your emergency commit and help ensure it doesn't make the problem worse.)
Second, having standard sanity/smoke tests run as pre-commit hooks means you can easily run those tests with one command – `git commit` – and not have to worry about either forgetting a test or forgetting to test entirely. Doing those tests as a post commit simply means you've possibly made a record of broken code and you'll probably just rebase before pushing. Doing test post push just means you're wasting others time with your noise or broken code. It's always best to expose problems as early as possible and to keep the influence of those problems as localized as possible.
This isn't to denigrate post push testing. I think it's extremely smart to have long running tests, ideally running on build or test servers, exercise a code base after a push and I think it's may be reasonable to notify many people when those tests fail, depending on the severity and scope of the failure. I just think that making it easy to run sanity/smoke tests and baking that into the infrastructure so it happens quickly and automatically is a smart move as well.
You could get the warnings and still exit with a 0 status and continue, or override the validations. Pre-commit hooks can still get you valuable information.
1) Sometimes (usually the worst times) you just need to check something in, maybe it doesn't pass pep8 but when service is down nobody gives a shit.
2) Instead of promoting thinking and caution it promotes attitude of "hey check it in and see if it sticks".
Post commit hooks that report broken tests, poor code, etc preferable to whole team are far superior. After first couple of times being shamed people will actually look over their code, run tests, run pep8, etc to verify the commit isn't bogus.