[Python-Dev] Hg: inter-branch workflow

[Guido van Rossum]

On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Mon, 21 Mar 2011 17:25:05 -0400
> Barry Warsaw <barry at python.org> wrote:
>> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>>
>> >I'd rather take a look at the final aggregate patch to see if it looks
>> >correct, actually. It's easy to have incremental changes which look
>> >good but lead to a questionable patch in the end. Better to review it
>> >in aggregate, IMO.
>>
>> I think it would be good to have the option to do either.
>
> Technically, nothing prevents anyone from committing many small
> changesets representing incomplete development. It's just that it
> pollutes history, similarly as it polluted history with SVN.

But what the best/right thing to do? Consider the following very
common scenario.

Let's say I'm working on a fairly substantial feature that may take
weeks to complete. My way of working is to explore different
approaches until I'm happy. I like to make checkpoints while I'm
exploring so that I can easily backtrack from experiments. I'm not
pushing any of this to the central repo; I'm just using a local repo.
Over a few weeks this can easily lead to 100+ commits. Occasionally I
push patches to Rietveld for review. When my reviewer and me are happy
we want to push my work to the core repo. But do you really want my
100 commits (many of which represent dead ends) in the core repo? Many
of them probably have checkin messages that make no sense to anyone.

I know I would be sorely tempted to use hg export + hg import (and
extensive testing after the latter of course) so that the approved
changes can land with a single thud in the core repo. But maybe I'm a
dinosaur?

-- 
--Guido van Rossum (python.org/~guido)