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.hettin...@gmail.com>wrote: > > On Dec 13, 2012, at 7:00 PM, Chris Jerdonek <chris.jerdo...@gmail.com> > wrote: > > > On Thu, Dec 13, 2012 at 6:48 PM, 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? > > > > 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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/timothy.c.delaney%40gmail.com >
_______________________________________________ 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