On Thu, Jul 1, 2010 at 15:07, Barry Warsaw <ba...@python.org> wrote: > On Jul 01, 2010, at 10:57 PM, Paul Moore wrote: > >>On 1 July 2010 20:58, Brett Cannon <br...@python.org> wrote: >>> Here is a *really* quick-and-dirty approach for non-committers to >>> create a patch they can submit. This is not extensively tested so >>> some other Hg expert should back me up on this before telling anyone >>> that this is the simplest way. I am also not saying this is how we >>> will want people to contribute in the long run, but this does work >>> and matches how svn does things well enough that people shouldn't get >>> thrown by the details. >>> >>> 1. Contributor clones the repo >>> 2. Contributor makes changes, committing as they go >>> 3. Contributor runs ``hg outgoing --patch --git > patch.diff`` >>> 4. Committer runs ``hg patch --no-commit patch.diff`` >>> 5. Committer does the usual review->commit thing >>> >>> Basically this creates git-style diffs that one can shuttle around. I >>> think you can also use ``patch -p1`` or git-apply to apply the patch >>> generated by Mercurial. >> >>I'd suggest the patchbomb extension (distributed with Mercurial) >> >>hg email --outgoing --to d...@somewhere sends a series of patches to >>the given email address. This is what the Mercurial developers use >>(with the to address being the mercurial-dev list). Or maybe better, >>hg email --outgoing --bundle which sends a binary bundle of all >>outgoing changesets. You can use --to to send the email to something >>like roundup (will Roundup extract an attachment from an email and add >>it to the issue as a file? That would be particularly neat...) > > Wouldn't it be cool if we could hook this up to Rietveld?
Don't see why not; it already has Hg support, IIRC. > > Other than that, while I sometimes review patches in email, I do not think > patches in a tracker are the best way to manage these. A dvcs's biggest > strength is in branches, so we should use those as much as possible. As I said, quick-and-dirty. It will take discussion to decide what we want to ask non-committers to do, weighing cost of complexity of the approach for people new to DVCS in general and Hg in particular, resource access such as a publicly accessible place to push repos, what data format we prefer, etc. I just wanted to give David something to go to PyOhio with that I know will be simple to explain and will always work. _______________________________________________ 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
