> On Nov 29, 2014, at 7:15 PM, Alex Gaynor <alex.gay...@gmail.com> wrote: > > Donald Stufft <donald <at> 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.
I also don’t know how to do this. When I’m doing multiple things for CPython my “branching” strategy is essentially using hg diff to create a patch file with my “branch” name (``hg diff > my-branch.patch``), then revert all of my changes (``hg revert —all —no-backup``), then either work on a new “branch” or switch to an old “branch” by applying the corresponding patch (``patch -p1 < other-branch.patch``). > > The seconds experience I have is that of Django's migration to git and github. > For a long time we were on SVN, and we were very resistant to moving to > DVCS in > general, and github in particular. Multiple times I said that I didn't see how > exporting a patch and uploading it to trac was more difficult than sending a > pull request. That was very wrong on my part. > > My primary observation is not about new contributors though, it's actually > about the behavior of core developers. Before we were on github, it was fairly > rare for core developers to ask for reviews for anything besides *gigantic* > patches, we'd mostly just commit stuff to trunk. Since the switch to github, > I've seen that core developers are *far* more likely to ask for reviews of > their work before merging. I’ve also seen this effect, not just in Django but that I also notice my own behavior. Projects where I have commit access but which aren’t on Github I find myself less likely to look for others to review them and find myself just committing directly to master/default/trunk while I do tend to look for reviews and create PRs to give others the chance to review on Github. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA _______________________________________________ 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
