It looks like the vote was not "unanimous"
https://mail.python.org/pipermail/core-workflow/2016-January...
Python moves to GitHub
51–60 of 119 posts
Re: Python moves to GitHub
#52this is pretty significant; so far the only git presence of Python was a "semi-official readonly mirror" on github: https://github.com/python/cpython now does this mean that Python will completely switch away from Mercurial? this was one of the major projects still using hg what does this mean for mercurial's global adoption vs git? also, i don't understand why the free software aspect of gitlab wasn't an important a…
Well, Facebook is probably the single largest corporate user of Hg in terms of repo size and investment into the tool. In terms of influencing global adoption, they probably pull more weight in the community than Python did.
This is true, since most of the hg devs are affiliated to Facebook, including lead dev mpm.
Re: Python moves to GitHub
#53Earlier quoted context omitted.
I'd consider "single sign on that connects me to tons of projects' repos to be great UX. Personally, it (and the centralized API) are big reasons I use GitHub to interact with projects whenever possible
Centralizing the "hub" pretty much negates the distributed aspect of a dvcs, and github has no incentive to invest in extending git to be even more distributed ala fossil or bittorent, to mention two not quite fitting but conveying the point examples. Maybe git-appraisal will grow into something good.
[deleted]
Re: Python moves to GitHub
#54Earlier quoted context omitted.
There are some things you simply can't do on GitHub: * block trolls from interacting with an organization, short of filing a support ticket * install pre-receive hooks without using the pull request infrastructure * set up status checks (the PR equivalent of pre-receive hooks) for pull requests that require force pushes, allowing some external check to replace git's usual fast-forward check * have status checks apply…
> On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :) That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.
Like GitLab?
Re: Python moves to GitHub
#55Earlier quoted context omitted.
Centralizing the "hub" pretty much negates the distributed aspect of a dvcs, and github has no incentive to invest in extending git to be even more distributed ala fossil or bittorent, to mention two not quite fitting but conveying the point examples. Maybe git-appraisal will grow into something good.
This gets brought up pretty much every time GitHub is mentioned on here, and I've never understood it. Using a hosted service like GitHub as a remote for your git repo doesn't "negate" the distributed aspect, any more than parking your car somewhere negates its ability to drive around. I can use GitHub as a remote and take advantage of the social and UX aspects they offer, and if GitHub vanishes (or has downtime), I…
I don't know how git-lfs is distributed.
Yes, you can still use the basic git features, and github doesn't break them. The problem is that instead of turning Git into a Fossil++, we're relying solely on Github's tooling around git. Yes, it's easier to have a centralized location that doesn't require synchronization for tickets and reviews, but when you have to move off github, you cannot really export all the history properly without losing some details, so I firmly believe we have to make more of the git story distributed. Those features can be used by github in a friendly web interface, but like the git push and fetch model, it should exist in git itself. That way, it really won't matter where users make contributions, and it will solve the Phabricator vs github dilemma for big projects, plus allow for full archiving and porting of the data. Once your tickets and diff reviews are part of the git repository, you get features that enhance the user experience. I believe git-appraisal is using git's notes feature, and that's a good way to avoid extending the data model.
Re: Python moves to GitHub
#56Earlier quoted context omitted.
I'd consider "single sign on that connects me to tons of projects' repos to be great UX. Personally, it (and the centralized API) are big reasons I use GitHub to interact with projects whenever possible
Centralizing the "hub" pretty much negates the distributed aspect of a dvcs, and github has no incentive to invest in extending git to be even more distributed ala fossil or bittorent, to mention two not quite fitting but conveying the point examples. Maybe git-appraisal will grow into something good.
The negation is that we centralize important data like code reviews and tickets in an external place that can be easily lost. Without those, most git repositories fail to tell the full history of a project.
Re: Python moves to GitHub
#57Earlier quoted context omitted.
> On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :) That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.
Like GitLab?
Is GitLab federated?
Re: Python moves to GitHub
#58Earlier quoted context omitted.
> On the other hand, the usable interface of GitHub wouldn't be available to you if you were using a regular UNIX-based git server, and that is a dealbreaker. :) That would be one hell of an open source project: a github like UI + ticketing system but federated rather than hosted by a central authority with some kind of single sign-on mechanism.
Like GitLab?
Good point, gitlab is probably 90% there already.
Re: Python moves to GitHub
#59Earlier quoted context omitted.
This gets brought up pretty much every time GitHub is mentioned on here, and I've never understood it. Using a hosted service like GitHub as a remote for your git repo doesn't "negate" the distributed aspect, any more than parking your car somewhere negates its ability to drive around. I can use GitHub as a remote and take advantage of the social and UX aspects they offer, and if GitHub vanishes (or has downtime), I…
I don't know how git-lfs is distributed. Yes, you can still use the basic git features, and github doesn't break them. The problem is that instead of turning Git into a Fossil++, we're relying solely on Github's tooling around git. Yes, it's easier to have a centralized location that doesn't require synchronization for tickets and reviews, but when you have to move off github, you cannot really export all the history…
As I noted, their API lets you export the data they add: issues, wiki, PRs, and the like. And git-lfs lets anybody run their own large file systems, backed however they want, without GitHub being involved.
If you're arguing that open source and self-hosted alternatives get better at the UX and communal aspects that GitHub has been excelling at, I'm all for it. But lets not sell short that the reason people are flocking to GitHub is because what it offers has value, value which is worth using a hosted centralized service for them.
Re: Python moves to GitHub
#60Earlier quoted context omitted.
What does "punished socially" even mean? Unable to attract as many contributors? The cold reality is that most open source projects aren't really TRYING to attract contributors. Small-time hobbyists often don't want to play with others in their personal project sandboxes, and big-time projects with high profile usually put up high barriers to contribution. Unable to attract as many end-users, or as much public mindsh…
Because of how Git is a distributed model, hosting your project on Github shouldn't be a big deal. You could host your project privately and then just have Github mirror that private host with hooks. Git being distributed means that you can host your project on as many different places as you want. And making the workflow to accept pull requests for Github, Gitlab, or other providers really isn't very difficult. They…
Because of how Git is a distributed model
News flash: the number of people using the "D" in "DVCS" is so tiny that it might as well not be there. Central server with central authoritative repository, where all developers push and pull and synchronize, is how people use git in the real world, and it's time to stop pretending that any distributed features will ever be used.
(which is to say, if github disappeared tomorrow, everyone using it would find a way to transition to yet another central server with central authoritative repo that everyone uses)