On Sun, Nov 30, 2014, at 11:45, Donald Stufft wrote:
On Nov 30, 2014, at 11:28 AM, Brett Cannon <brett@python.org> wrote:
On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor <alex.gaynor@gmail.com <mailto:alex.gaynor@gmail.com>> wrote: Donald Stufft <donald <at> stufft.io <http://stufft.io/>> writes:
[words words words]
I strongly support this PEP. I'd like to share two pieces of information. Both of these are personal anecdotes:
For the past several years, I've been a contributor on two major projects using mercurial, CPython and PyPy. PyPy has a strong culture of in-repo branching, basically all contributors regularly make branches in the main repo for their work, and we're very free in giving people commit rights, so almost everyone working on PyPy in any way has this level of access. This workflow works ok. I don't love it as much as git, but it's fine, it's not an impediment to my work.
By contrast, CPython does not have this type of workflow, there are almost no in-tree branches besides the 2.7, 3.4, etc. ones. Despite being a regular hg user for years, I have no idea how to create a local-only branch, or a branch which is pushed to a remote (to use the git term). I also don't generally commit my own work to CPython, even though I have push privledges, because I prefer to *always* get code review on my work. As a result, I use a git mirror of CPython to do all my work, and generate patches from that.
The conclusion I draw from this is that hg's workflow is probably fine if you're a committer on the project, or don't ever need to maintain multiple patches concurrently (and thus can just leave everything uncommitted in the repo). However, the hg workflow seems extremely defficient at non-committer contributors.
One way to come close to that using hg is to have your own clone that you never push to hg.python.org/cpython <http://hg.python.org/cpython> (e.g. cloning the Bitbucket clone of cpython or hosting on hg.python.org <http://hg.python.org/> a personal clone). You can then specify the repo and branch on the issue tracker to generate your patch: https://docs.python.org/devguide/triaging.html#mercurial-repository <https://docs.python.org/devguide/triaging.html#mercurial-repository> . After that it's just like any other patch workflow for core devs. It's not quite as nice as maybe using named branches where you can just do a final hg merge/commit to get your changes committed, but if you're not going to commit your branches then you might as well get the automatic patch generation perk in the issue tracker rather than using git (unless there is some other git feature you use that you can't get in hg).
This doesn’t really work in a Pull Request workflow though I think is the point. Uploading patches is it’s own kind of terrible but yes if you’re just uploading patches you can probably do that. I don’t make branches in Mercurial because i’m afraid I’m going to push a permanent branch to hg.python.org <http://hg.python.org/> and screw something up.
Don't worry; we have a hook for that.