In article <20121214024824.3bccc250...@webabinitio.net>, "R. David Murray" <rdmur...@bitdance.com> wrote: > On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson <tr...@snakebite.org> wrote: > > - Use a completely separate clone to house all the intermediate > > commits, then generate a diff once the final commit is ready, > > then apply that diff to the main cpython repo, then push that. > > This approach is fine, but it seems counter-intuitive to the > > whole concept of DVCS. > > Perhaps. But that's exactly what I did with the email package changes > for 3.3. > > You seem to have a tension between "all those dirty little commits" and > "clean history" and the fact that a dvcs is designed to preserve all > those commits...if you don't want those intermediate commits in the > official repo, then why is a diff/patch a bad way to achieve that? If > you keep your pulls up to date in your feature repo, the diff/patch > process is simple and smooth.
Also, if you prefer to go the patch route, hg provides the mq extension (inspired by quilt) to simplify managing patches including version controlling the patches. I find it much easy to deal that way with maintenance changes that may have a non-trivial gestation period. -- Ned Deily, n...@acm.org _______________________________________________ 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
