[python-committers] Create a Mercurial repository with a branch per issue

[Dirkjan Ochtman]

On Fri, Feb 4, 2011 at 14:31, Tarek Ziadé <ziade.tarek at 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