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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4