[Python-Dev] Mercurial workflow question...

[Tim Delaney]

Possibly. A collapsed changeset is more likely to have larger hunks of
changes e.g. two changesets that each modified adjacent pieces of code get
collapsed down to a single change hunk - which would make the merge
machinery have to work harder to detect moved hunks, etc.

In practice, so long as each collapsed changeset is for a single change I
haven't seen this be a major issue. However, I'm personally a "create a new
named branch for each task, keep all intermediate history" kind of guy (and
I get to set the rules for my team ;) so I don't see collapsed changesets
very often.

Tim Delaney


On 17 December 2012 16:17, Raymond Hettinger <raymond.hettinger at gmail.com>wrote:

>
> 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
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/timothy.c.delaney%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121217/532a9da6/attachment.html>