On Fri, Feb 4, 2011 at 14:31, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
That's why I think it's much cleaner to work with mq to build a clean single-commit patch, even if a clone may be used for temporary states and sharing.
We are experiencing merge hell right now in Distutils2, as the contributor list grows, because of the way people work with clones. We are polluting history with a lot of "merge" commits because it's the most simple way to work w/ mercurial.
Yeah, it seems like you might want to ask more people to use mq or rebase (either way works -- or just pull and update just before your commit).
IMO people should always rebase locally before committing, so that merges aren't generally required for that. Only if their work has gone really stale (some large refactoring landed in the mean time) it might be worth it to explicitly record the merge.
I think extra clones per issue could work for some larger issues that require lots of work, but I don't think the every-small-feature-on-a-branch model (as practiced in Twisted, IIRC) is particularly helpful. On the other hand, I do think it's helpful to publish changes as multiple commits (where the test suite passes at each separate stage of the larger change).
Cheers,
Dirkjan