[Python-Dev] Using feature branches for local development

[Éric Araujo]

tl;dr: +1 for pushing only clean changesets.

Le 13/03/2011 14:44, Antoine Pitrou a écrit :
> I think we (python-dev) will need to take a decision on this.
> 
> My personal opinion is that we don't want to see all intermediate
> commits which led to a patch (or feature) in the main repo. It may
> also lead to many spurious buildbot builds (some of them probably
> failing), and many commit notifications on python-checkins: you could
> see an example of the latter with the distutils2 pushes.
> 
> The counter-argument is that preserving the development history can
> make changes more understandable. That's only if the history reflects
> the logical separation of changes, though.
> 
> If someone wants to split their work into several changesets, a patch
> series using mq could also be the recommended way (that's how
> mercurial-devel works).

Agreed.  +1 on pushing only clean changesets instead of a whole series
with different versions and fixes.  Most of the time that will be one
changeset, and when it makes the changes easier to read, more than one
(say for a fix in a docstring and doc file followed by a rewrite of that
part of the doc file).  I also think that it should be allowed to merge
a feature branch (unnamed!) that has taken some time to complete and
thus has many changesets (think io-in-c), as long as they are clean too:
It will be the same situation as with Subversion, only with nicer merge
changesets.

On another hand, it can be useful to see the whole life of a patch, but
this can be achieved by saving the repo with the intermediate changesets
somewhere.  Having unclean changesets with dead ends and fixes can have
educational value and help break the impression that developers don’t
make mistakes, which can prevent people from trying to contributing (for
more about that, see The Myth of the Programmer Genius:
http://www.youtube.com/watch?v=XeJSXfXep4M).

For a previous discussion about flattening a branch into a patch or not,
see http://mail.python.org/pipermail/python-ideas/2010-July/007538.html
(thread started by Tarek).

Finally, I’d say that using named branches or clones or MQ is the choice
of the developer; history editing is built-in with MQ, extensions like
collapse and histedit can work with branches, hg diff + import can
flatten too, so we don’t have to mandate one tool.  MQ is very powerful
and can be a life-saver, but its conflict handling is not as cool as
Mercurial’s, and I’ve had good success in cleaning branches with other
tools.

Regards