[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

[Donald Stufft]

> On Nov 29, 2014, at 7:15 PM, Alex Gaynor <alex.gaynor at 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