[Python-Dev] Mercurial workflow question... (original) (raw)

Raymond Hettinger raymond.hettinger at gmail.com
Mon Dec 17 06:17:08 CET 2012

On Dec 13, 2012, at 7:00 PM, Chris Jerdonek <chris.jerdonek at gmail.com> wrote:

On Thu, Dec 13, 2012 at 6:48 PM, R. David Murray <rdmurray at bitdance.com> wrote:

On Thu, 13 Dec 2012 20:21:24 -0500, Trent Nelson <trent at 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? Right. And you usually have to do this beforehand anyways to upload your changes to the tracker for review. Also, for the record (not that anyone has said anything to the contrary), our dev guide says, "You should collapse changesets of a single feature or bugfix before pushing the result to the main repository. The reason is that we don’t want the history to be full of intermediate commits recording the private history of the person working on a patch. If you are using the rebase extension, consider adding the --collapse option to hg rebase. The collapse extension is another choice." (from http://docs.python.org/devguide/committing.html#working-with-mercurial )

Does hg's ability to "make merges easier than svn" depend on having all the intermediate commits? I thought the theory was that the smaller changesets provided extra information that made it possible to merge two expansive groups of changes.

Raymond

More information about the Python-Dev mailing list