Home Original page

[Python-Dev] Mercurial workflow question...

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