On Sun, Nov 30, 2014, at 11:45, Donald Stufft wrote: > > > On Nov 30, 2014, at 11:28 AM, Brett Cannon <br...@python.org> wrote: > > > > > > > > On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor <alex.gay...@gmail.com > > <mailto:alex.gay...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
