On Nov 29, 2014, at 7:15 PM, Alex Gaynor
wrote: Donald Stufft
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