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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
