On 08/16/2015 07:08 AM, Guido van Rossum wrote:

I presume the issue here is that Hg is so complicated that everyone knows a different subset of the commands and semantics.

I personally don't know what the commands for cherry-picking a revision would be.

There are a couple. The command you'd want for this use case is probably "hg transplant", because it lets you pull revisions from a different repo. Note that "transplant" is an extension; it's distributed with Mercurial but is turned off by default. (Presumably because it's an "unloved" feature, which seems to translate roughly to "deprecated and only minimally supported".)

The Mercurial team recommends "graft", and they also provide "rebase", but neither of those can pull revisions from another repo.

Since all revisions committed to 3.5.0 should be merged into 3.5.1 sooner or later, personally I don't see the *need* for cherry-picking.

I also don't know exactly what happens when you merge a PR using bitbucket. (I'm only familiar with the GitHub PR flow, and I don't like its behavior, which seems to always create an extra merge revision for what I consider as logically a single commit.)

Bitbucket doesn't appear to create any extraneous merge revisions. Of the two PRs I've accepted, only one created a merge, and that was sensible.

BTW When I go to https://bitbucket.org/larry/cpython350 the first thing I see (in a very big bold font) is "This is Python version 3.6.0 alpha 1". What's going on here? It doesn't inspire confidence.

It was displaying the readme from the default branch. We use the 3.5 branch.

I just went and looked, and there's a "default branch" option for the repo on Bitbucket. I changed it from "default" to "3.5" and now it displays "This is Python version 3.5.0 release candidate 1". Hopefully that inspires more confidence!

/arry