On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 21 Mar 2011 17:25:05 -0400 > Barry Warsaw <ba...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
