[Python-Dev] Using feature branches for local development

[Benjamin Peterson]

2011/3/13 Antoine Pitrou <solipsis at pitrou.net>:
> On Sun, 13 Mar 2011 09:28:28 -0400
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> > The mercurial-recommended way is that you just push your changes to cpython
>> > when done, which puts all your individual commits into Python's history.
>> >
>> > I tried to find an official statement on which way it should be in the
>> > devguide, but couldn't find anything.
>>
>> It's definitely the latter, but I don't think it is explicitly
>> documented yet that this applies to all pushes, not just patches from
>> the tracker.
>
> 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.

+1 for collapsing commits into logical patches. Little is more
annoying than annotating something and finding out the commit message
was "oops, fix this thingy..." completely out of context of the larger
patch.

>
> 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).



-- 
Regards,
Benjamin