
Python moved to GitHub - c8g
https://github.com/python/cpython
======
payne92
Part of Github's secret sauce: Web source tree browsing that's front and
center, that's relatively decent, with OK search. (versus making the
log/history the central part of the Web UI as other tools seem to do)

There are SO many times I need a short peek at something, and am glad don't
have to clone/download, etc.

~~~
Stratoscope
> Web source tree browsing that's front and center, that's relatively decent,
> with OK search.

The source browsing feels barely adequate to me. There are so many simple
things they could do to make it better.

• Show file sizes. When I'm exploring a repo I'm unfamiliar with, one thing
that's helpful for me is to get a sense of what the code is like. To do this,
I want to look at some of the larger files; that's where I'll probably find
the more interesting code. As it is I just click around on random files hoping
to find something interesting.

• Show real dates instead of the vaguely rounded off "how long ago". If it
says "a month ago", well, what is it, two weeks or six? And why not show the
time? A couple of times I've been looking for a code change and I didn't
remember what day it was but I did remember it was right before lunch, maybe
around 11:30 or so. It feels like their priority is a "clean and simple"
display as opposed to a _useful and informative_ display.

• Fix the display for code that indents with tabs. It still defaults to 8
columns, which hardly anyone (with a few notable exceptions) likes. And you,
the user, can't override this. They did recently start honoring the
indent_size setting if you have a .editorconfig file, but that really misses
the point. Many of us who use tabs don't _want_ to specify an indent_size.
That's one of the virtues of tabs: people who read the code can use whatever
indentation they prefer. The indent size for tabs should be a user preference
setting. As it is, I started adding indent_size=4 to my .editorconfig files
just to get a decent looking display on GitHub.

• Use a readable font on mobile. Courier, really? And not such low contrast!
Everything is hard to read on mobile, and they even disabled pinch-zoom so I
can't make the text a little bigger.

• Show a directory tree on the left. If I'm exploring a repo, I'd like to get
the big picture of the directory layout, and also have an easy way to click
around to look at the various directories. As it is, I have to do a lot of
back and forth. Google Code had this from the beginning.

Edit: Thank you everyone for the helpful replies! I learned some great tips
from you all.

~~~
timdorr
> Show file sizes

Those are at the top of the display of file contents. However, they aren't in
the tree view, as you've stated. Unfortunately, this is hard because I don't
believe Git stores this info in their index of files, which is what is used to
generate the tree view. It might be infeasible to gather that data for the
tree view.

> Show real dates instead of the vaguely rounded off "how long ago".

If you hover over any relative date, the real date is shown. It's on the title
attribute for any relative date.

> Use a readable font on mobile.

The have Consolas and "Liberation Mono" on the font stack, but those probably
aren't on your phone. They are limited in font selection because they have
switched to native fonts. This avoids the download of some giant font file
that contains all the possible glyphs (which is needed on a site like
GitHub's). Unfortunately, the monospace options on mobile are pretty limited:
[http://iosfonts.com/](http://iosfonts.com/)

> Show a directory tree on the left.

Best tip I can offer is to type `t` to search by file name. Works great and
has partial matching support, which makes it really quick to navigate to
certain key files.

~~~
benhoyt
It's pretty cheap to get the file size with decompressing the whole blob. You
can decompress just the first hundred of so bytes of the .git blob object,
which starts with "blob {size}\x00". For example, using Python:

    
    
       >>> import zlib
       >>> f = open('.git/objects/00/331d4c2e12984f70df4a3dd3bc7296825faab0', 'rb')
       >>> zlib.decompressobj().decompress(f.read(100))
       b'blob 11708\x00...'
    

So that particular file is 11708 bytes. It still requires an open and read
operation. But they could cache that on a per-file or per-tree basis, so it's
very doable.

~~~
timdorr
At least until you try to open up [https://github.com/Homebrew/homebrew-
core/tree/master/Formul...](https://github.com/Homebrew/homebrew-
core/tree/master/Formula) :)

------
laurentdc
Yes!

I quite like the idea of "centralizing" development on GitHub, or similar
services. It makes it much easier for everyone to fork, test, make a pull
request, merge, etc..

For example, one reason why I gave up contributing to OpenWrt was their
absolutely legacy contribution system [1], which required devs to submit code
diff patches via email (good luck not messing up the formatting with a modern
client) on a mailing list. It took me an hour to submit a patch for three
lines of code. It seems like Python wasn't much different. [2]

[1]
[https://dev.openwrt.org/wiki/SubmittingPatches#a1.Creatingap...](https://dev.openwrt.org/wiki/SubmittingPatches#a1.Creatingapatch)

[2]
[https://docs.python.org/devguide/patch.html](https://docs.python.org/devguide/patch.html)

~~~
ycmbntrthrwaway
Centralizing around proprietary software is not a good idea generally.

Git is distributed, so when GitHub goes down, every developer has a backup of
entire history. However, issues are lost forever. Python does not use "issues"
feature for good.

One way to avoid email without centralization is setting up Gerrit. That is
how Ring [1] and LineageOS (former CyanogenMod) [2] manage their "pull
requests".

Still, being able to submit patches via email is an absolutely necessary skill
for everyone who considers himself a hacker. Lack of it makes you unable to
contribute to many great projects, such as all suckless [3] projects and Linux
itself.

[1] [https://gerrit-ring.savoirfairelinux.com/](https://gerrit-
ring.savoirfairelinux.com/)

[2] [https://review.lineageos.org/](https://review.lineageos.org/)

[3] [http://suckless.org/](http://suckless.org/)

~~~
ajdlinux
Everyone I know who has had to use Gerrit has _absolutely, utterly despised_
it.

Until I got a job working as a kernel developer I had never had to use emailed
patches. It simply isn't an "absolutely necessary" skill for a good developer
these days.

The kernel community is too attached to email patch submission for it to ever
move away, and to be fair, email does have the benefit of being scalable and
matches our decentralised workflow much better than any of the current
alternatives.

But it's still not _good_. There are plenty of ways to screw up email
threading or forget conventions on labelling patchset versions or whatever
(this happens _all the time_ ). You have to rely on external tools such as
Patchwork to provide a bare minimum of state-tracking. There's not much by way
of generic CI tooling that's designed with email in mind (I'm working on
this!). Doing code review from an email client definitely has its benefits,
but it's also limiting - web-based code review tools have much more scope for
experimenting with better ways of presenting comments.

I can't see the Linux kernel ever moving away from email, and honestly it's
not too bad once you've figured out your workflow, but I would like to see
kernel _hackers_ thinking about what it is that the kernel community loves so
much about email compared to GitHub and other centralised services. It _is_
disappointing to see other large open source projects becoming incredibly
dependent on a for-profit proprietary software company that may well not
survive the next few years. How can we do proper decentralised version control
and development _better_?

~~~
rando832
I used gerrit and did not utterly despised it. Hi.

~~~
mugsie
I have been using it for a few years, and I miss it when I am working on
github projects :/

------
di
More details on the decision:

[https://snarky.ca/the-history-behind-the-decision-to-move-
py...](https://snarky.ca/the-history-behind-the-decision-to-move-python-to-
github/)

~~~
fairpx
this just adds to the mystery

------
misnome
Why on earth have they done:

> Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
> 2011, 2012, 2013, 2014, 2015, 2016, 2017

Rather than just

> Copyright (c) 2001-2017

~~~
slizard
This is why: "For software with several releases over multiple years, it's
okay to use a range (“2008-2010”) instead of listing individual years (“2008,
2009, 2010”) if and only if every year in the range, inclusive, really is a
“copyrightable” year that would be listed individually; and you make an
explicit statement in your documentation about this usage."

Source: [https://www.gnu.org/licenses/gpl-
howto.en.html](https://www.gnu.org/licenses/gpl-howto.en.html)

~~~
uiri
Every year from 2001 to 2017 inclusive is listed so this is not the reason.

~~~
slizard
Sure, in this particular file every year in the interval is listed, but in a
large codebase that's not always the case. Always listing every year keeps
things simple, consistent, avoids complications around extra statement and
clauses, and makes auto-generating headers easier.

------
agentgt
This is a little disappointing for several reasons. I understand the merits of
GitHub but I really wish Python at least stuck with Mercurial repository and
some decentralization.

It's especially sad because Mercurial is just now starting to be incredibly
powerful with evolutions.

I guess I'm an old fart but all the centralization has made me paranoid and I
still absolutely prefer Mercurial (albeit with plugins) over git.

~~~
dbcurtis
Bah. Anybody can clone a git repo. It's trivial to move off of github with a
git repo if they want, or possible to migrate to another database if they want
to go through the disruption.

Going to git is about gaining developer mindshare. There are more people using
git now. So being on git will bring in more "drive by pr's". I know for my
part, life is too short to keep current on multiple source code control tools.
I've done plenty in my time, but git is where I'm at now. I use git now at
work, and until now, all of the hobby projects that interested me except for
1, were on git. Now all are on git.

At PyCon 2016 Guido told the story of how Mercurial was selected over git. It
seemed like an even match at the time. Guido is very source-code-control-tool-
agnostic. But git is the current best path to enabling more people to help
with cpython development.

~~~
agentgt
It is hardly trivial to move off. Bugs would have to be migrated, links
updated, documentation, automated build systems, workflow as well as user
remapping.

While not being Mercurial is one thing it is really more about being on GitHub
that is the problem. Kings will get complacent (remember how long it took to
GitHub to add some features).

I also vaguely remember the github guys trashing Mercurial with arguabley a
propaganda campaign (something "git is better than X"). All that content is
missing now but I do remember (I'll have to look on way back machine later).

------
tbrock
Wow if only we could get Gnome and Linux on there and give up this mailing
list for patches nonsense we'd be golden.

------
Fice
This is scary. For increasingly many potential contributors a project
effectively does not exist if it is not on GitHub. And, being a huge
centralized service, GitHub is very susceptible to censorship (e.g. repos
being taken down via DMCA or Russia blocking GitHub until they started to
cooperate with the censors). I see this dependence as very bad and dangerous
for the free software movement. Should we even consider convenience of a
service that has serious ethical issues?

~~~
chaostheory
Why is it scary? Is it that hard to move to bitbucket, gitlab, or another
alternative git host if needed?

~~~
Fice
This is not about how hard or easy it is to move from GitHub. What scares me
is that it is increasingly hard to participate in the open source/free
software community without using GitHub, and it is increasingly hard to find
contributors for your own project if you are not willing to host it there.

~~~
chaostheory
Why is it scary to use Github? Is there some hidden cost that people aren't
aware of?

~~~
Fice
The programming community became globally dependent on a single commercial
company. Using GitHub would mean contributing to that dependence and
monopolization even more.

~~~
chaostheory
Is anyone really dependent when the cost to switch to a different provider is
low? You haven't given a good reason.

~~~
Fice
It's not just about moving data from one provider to another. GitHub is not
simply a hosting service, it's a large centralized social network, and the
cost of switching from it includes reduced project visibility and
disconnection from the community.

~~~
chaostheory
These may be issues for smaller projects, but I don't feel that either
visibility or community is a problem for a project like Python. They have the
luxury of going wherever they want and people will follow.

------
EvgeniyZh
I'd really like more big and important projects would move their development
to GitHub-styled services. Maybe I'm just not hardcore enough, but I feel they
make live easier, both for maintainers, contributors and newcomers.

But it's probably too hard to switch and core developers don't see point in it
(since they're totally ok with working their way). Maybe when a new generation
developers will take core positions...

~~~
hvidgaard
The idea of GitHub is great, and frightning at the same time. The development
community as a whole would be crippled if GitHub went under. Same thing with
StackOverflow.

I'm still dreaming of a decentralized GitHub based on something like ipfs.

~~~
EvgeniyZh
Well, local running copy GitLab (or something other GitHub-styled) with a
couple of backups is pretty safe and still gives all the advantages of GitHub.

Decentralized GitHub is a nice idea. We gotta implement this)

------
anamoulous
Wow the black bar settled it for them, huh?

~~~
ambivalence
I know you're joking but just for the record: this process was started in late
2015, it's a surprisingly complicated endeavour to switch source control
hosting.

------
hueving
Sad day. Don't forget that github is a closed source tool. This is equivalent
to them announcing they are switching to Jira.

~~~
Karunamon
Both of those products allow for trivial data import/export. What exactly is
the problem?

~~~
hueving
They are closed source. People that are really serious about open source
software from top to bottom have issues with dependencies on closed source
tooling because it promotes an ethos they don't support.

~~~
Karunamon
Ah.. I was hoping there was a substantial practical reason that I had
overlooked.

~~~
hueving
Ah, the classic open source freerider. Only support it when convenient, ignore
every other situation.

------
jwilk
[https://news.ycombinator.com/item?id=13614253](https://news.ycombinator.com/item?id=13614253)

------
imode
I'd question why it wasn't GitLab but after the recent outage it would
somewhat be in bad taste. :P

what exactly was Python using before/where was it hosted? all I can find are
the source archives on python.org. I'm assuming this wasn't a hard transition
but I'm genuinely curious as to their development strategy regarding
distribution of source.

~~~
grzm
There are at least two comments in this thread that address this issue:

\-
[https://news.ycombinator.com/item?id=13633369](https://news.ycombinator.com/item?id=13633369)

\-
[https://news.ycombinator.com/item?id=13633271](https://news.ycombinator.com/item?id=13633271)

------
jaimebuelta
Background info about why this migration and considered alternatives

[https://snarky.ca/the-history-behind-the-decision-to-move-
py...](https://snarky.ca/the-history-behind-the-decision-to-move-python-to-
github/)

------
dbalan
So python eventually moved to git from mercurial.

~~~
harry8
I'm not sure that's correct.

[https://hg.python.org/cpython/](https://hg.python.org/cpython/)

~~~
kzrdude
It is, though

~~~
harry8
Well that sure settles things. I'm totally sure now.

Guido's last commit, in both the github repo and the mercurial repo.

[https://github.com/python/cpython/commit/934aba66ef09e94422b...](https://github.com/python/cpython/commit/934aba66ef09e94422bcac86dd221011242e141d)

[https://hg.python.org/cpython/rev/3db1959c2c53](https://hg.python.org/cpython/rev/3db1959c2c53)

Someone sensible may be able to shed some light on it. Presumably there's a
bridge between the two somewhere.

~~~
detaro
Per PEP 512
([https://www.python.org/dev/peps/pep-0512/](https://www.python.org/dev/peps/pep-0512/)):

 _This PEP outlines the steps required to migrate Python 's development
process from Mercurial [3] as hosted at hg.python.org [1] to Git [4] on GitHub
[2]_

[...]

 _The fate of hg.python.org

With the code repositories moving over to Git [4] , there is no technical need
to keep hg.python.org [1] running. Having said that, some in the community
would like to have it stay functioning as a Mercurial [3] mirror of the Git
repositories. Others have said that they still want a mirror, but one using
Git.

As maintaining hg.python.org is not necessary, it will be up to the PSF
infrastructure committee to decide if they want to spend the time and
resources to keep it running. They may also choose whether they want to host a
Git mirror on PSF infrastructure._

------
gigatexal
Python 3.7 already in the works. The effort to push python 3.x is picking up
steam it seems.

~~~
akuchling
Nothing surprising there. The version bump for 3.7 would have been committed
immediately after branching off the 3.6 release branch.

------
echelon
I can't help but think Gitlab would have been in contention for this move had
they not had the recent outage. Can anyone from the Python org comment on what
other choices were considered?

~~~
detaro
All this has been decided for months and the discussion about has been going
on for more than a year, so no, no recent outage could have been a factor. PEP
512 mentions why GitHub was choosen over GitLab.

[https://www.python.org/dev/peps/pep-0512/](https://www.python.org/dev/peps/pep-0512/)

~~~
tomcam
tl;dr -- Devs are more familiar with Github, and Python's creator also prefers
it (he modestly agreed to go with whatever the team decided and it appears
they very much wanted to grant him the courtesy).

------
rectangletangle
Where is the "issues" section? I wanna read about some gnarly low-level
CPython bugs!

Other than that, this is a welcome change.

~~~
_ZeD_
[http://bugs.python.org/](http://bugs.python.org/)

------
meneses
FYI, Python was on Github but it was the read-only version. You still had to
go to mercurial to push the updates.

------
lucidguppy
I wish PR's on github could be checked off per commit like in bitbucket.

------
faraggi
Anbody know what happend to Guido's contributions between 2008-2012?

Maybe he had kids. :P

------
napolux
Still waiting for WordPress to move. ;)

------
hayd
and nearly 100k commits... time to start making some PRs!

------
gkya
This is FUD. There are sensible responses to this comment, so I won't write a
new one, but say one thing: You don't know how to use conventional tools, and
and go on to blindly rant about them.

> Basically, e-mail is the death of any sort of low-effort contribution. If
> you're starting a new project, and chose a mailing list, you're probably
> excluding a huge quantity of potential contributors.

If those contributors are as incompetent to not be able to mail a patch, I'd
rather be happy to have excluded them.

~~~
fake-name
I think the core issue with your response is, unless the project in question
_is_ the "conventional tools", why do you seem to think knowing those tools is
even germane to the quality of someone's contributions?

I write python and some C++ stuff for fun in my free time. If your project
interests me, but I have to spend said free time to learn esoteric tools to
interact with it _that aren 't needed elsewhere in my life_, how do you figure
that's valid?

It's not that I couldn't _learn_ to deal with that kind of shit, it's that I
don't see why I should bother. If everything else works without e-mailed
diffs, all that does is make anyone with more then one hobby project do is
look elsewhere.

~~~
gkya
One way or another, one has to learn the conventional communication tools if
they want to contribute to any open-source project, be it GitHub or GitLab, or
a mailing list and debbugs. The maintainers get to decide and it's their way
or the highway. The project is theirs.

Some skills only serve one purpose. Like shaving. I learnt how to shave when I
was a teen, and that skill has only been useful to me in shaving my face,
since ten years. And being able to use email and diffs is a transferable
skill.

I won't respond to you anymore, as I dislike your language and your
contributions are trollish.

------
hexa-
I was recently hit by an IPv4 routing outtage and had only IPv6 available to
connect to the internet.

I was therefore unable to connect to github.com, as there is no IPv6 support
available:

% host github.com github.com has address 192.30.253.112 github.com has address
192.30.253.113

