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

[Chris Angelico]

On Mon, Dec 1, 2014 at 6:28 AM, Ethan Furman <ethan at stoneleaf.us> wrote:
> My issues with GitHub range from selfish to philosophical:
>
>   - (selfish) I don't want to learn git

This ties in directly with the popularity argument. How many people
are there who know hg and don't know git? How many who know git and
don't know hg? So while this is a git issue for you, it's going to be
a Mercurial issue for a lot more people.

(And even people like me who kinda know both are going to spend a lot
more time with git than with hg, on average. My knowledge of git is
fairly advanced - I use git hooks, have scripts that manage things for
me, can repair a repository that's seen some mess in it, etc - but my
Mercurial knowledge is basic - I can clone and pull, not even sure I
can push as I have literally never done so, and I basically turn to a
dev guide to figure out how to make a patch in the appropriate way.)

>   - (practical) from what I hear git can have issues with losing history -- in a
>     project that has many volunteer and part-time developers, using a tool that
>     can munge your data just doesn't seem very wise

It is possible to rewrite history in git, but - assuming you're not
going to go to the ridiculous extent of SHA-1 cracking - it'll always
be done by creating a new stream of commits, and git is very careful
about confirming that you want to do this sort of thing. When you have
a central server, you can simply configure it to reject any
non-fast-forward pushes. (I'm not sure how to set
receive.denyNonFastForwards on GitHub, but it's likely to be possible.
In any case, you can always have an authoritative clone on python.org
somewhere which mandates this kind of thing.)

The git philosophy is: Your repository is yours. What you do with it
is up to you. If that means rewriting history, git will confirm with
you that you really want to do that, and then go right ahead and do
what you ask. But then if your repo is a clone of someone else's,
well, that someone else controls the other repo, so you might well not
be allowed to merge changes in.

>   - (practical) supporting git and hg means learning two different workflows

Already a problem for a lot of people. Unless CPython is the only
project you ever contribute to, chances are you're going to meet git
somewhere. If CPython used some mindblowingly brilliant but utterly
unheard-of DVCS, sure it might be possible for core devs to avoid
using any of the popular systems, but nobody else could.

Personally, and somewhat selfishly, I would love to see the PEPs repo
move to GitHub. For the two PEPs that I wrote, I had to juggle my own
personal PEP draft repo and the central Mercurial peps repo; making
sure changes got deployed from one to the other was basically a manual
job, without any tool support. If I could send PRs against a clone of
the peps repo, I would work that way instead of creating a dedicated
repo at all (at least until such time as I need other files; the PEP
463 repo grew a few other bits and bobs, but they could just as easily
have been in an ancillary repo without the PEP text in it).

There'll be easily as many people who selfishly want git as selfishly want hg :)

ChrisA