Antoine Pitrou writes:
In addition, a DVCS brings in another problem dimension: when people push their changes, they have *already* committed them - and perhaps not even they, but a contributor from which they had been pulling changes. The bogus change may have been weeks ago, so the subversion solution (of rejecting the commit to happen) doesn't quite work that well for a DVCS.
git has a nice filter-branch command, which would allow you to automatically repair the problem (it works basically by checking out each changeset and rerecording it with the appropriate commands). I know bzr is growing something similar, so presumably it is or will soon be available in hg.
I don't think this problem is really serious. If the push fails, you can just commit (locally) a new changeset that repairs the EOL or indentation problems, and push the whole bunch of changesets again (I assume the server-side hook will not examine changesets individually, but only the last of them?).
That's not a very good solution. Especially with typical Mercurial workflows[1], it's quite possible that you'll have a number of bogus changesets interleaved with good one. I don't think recording a repair is satisfactory. Footnotes: [1] Note that DVCS means you do *not* have to follow Python workflows in your private branches.