Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python moves to GitHub

mail.python.org

Post reply on HN
Print view View original

101–110 of 119 posts

Re: Python moves to GitHub

#101

Post by geofft »

carussell wrote: post #96
geofft wrote: post #39

Earlier 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…

Something else that's IMO more important than any of those items is this: You can't submit patches. Submitting/accepting a patch is something that straight up cannot be done on GitHub. Unless you use a sidechannel like sending a message containing a link to a patch that you threw up on some host somewhere (in which case, have fun rooting out that information on a case-by-case basis), the only way to ever get any chan…

That third "copy" is a copy-on-write copy; it shares objects with its source. (In fact if you built a distributed version of GitHub, you'd have to figure out a more clever solution to this.)

It is true that the inability to submit a PR without a local clone is annoying. For the use case you describe, a one-line fix, note that GitHub has a web-based editor (that will create a fork if necessary), so you can skip the local branch entirely.

Someone could probably toss together a web service that does the equivalent of a `git clone --depth 1` behind the scenes and then applies your patch.

Re: Python moves to GitHub

#103

Post by tedmiston »

carussell wrote: post #96
geofft wrote: post #39

Earlier 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…

Something else that's IMO more important than any of those items is this: You can't submit patches. Submitting/accepting a patch is something that straight up cannot be done on GitHub. Unless you use a sidechannel like sending a message containing a link to a patch that you threw up on some host somewhere (in which case, have fun rooting out that information on a case-by-case basis), the only way to ever get any chan…

Is that really any different than GitLab though...?

Re: Python moves to GitHub

#104

Post by tracker1 »

carussell wrote: post #97
tracker1 wrote: post #85

Earlier quoted context omitted.

With self-hosting you don't get the broader community... With node, for example, most modules have source on github and it's easy to fork, fix/enhance something and submit a PR... with everyone self hosting, how many logins do you have to create. I know, tracking, federation, etc... but it's much nicer only having a couple logins (google, fb, twitter, github) for most sites I access regularly.

SSO is a separately solvable problem, and even so, I'm not sure it's a solution that needs applying here. It's not clear why any form of sign-on is needed—SSO or not. Almost everybody in this space is already using public-key crypto for authentication.

But not for signing into the website, and adding notes for a pull request, or filing a bug/issue/feature request.

Re: Python moves to GitHub

#105

Post by josegonzalez »

akerl_ wrote: post #19
rvense wrote: post #16

Earlier quoted context omitted.

Even the issue tracking?

Their API exposes issue data, and there are a handful of 3rd party API-based tools designed to back up / extract it. Also, for anybody not already aware (I didn't know this for a long time): GitHub repo wikis are themselves git repos that use Gollum

I've already written a standalone tool to do exactly this: https://github.com/josegonzalez/python-github-backup

Re: Python moves to GitHub

#107

Post by mineo »

gkya wrote: post #75
manigandham wrote: post #72

Earlier quoted context omitted.

What's the alternative? Everyone running their own little proprietary stacks with none of the features or community or ease of use?

It's easier than pull requests, to email a patch.

To be honest, I don't find this to be true. To email a patch, you usually have to

* figure out if you can use git-request-pull or git-send-email * sign up for a mailing list (which, depending on the mailing list software the project uses, can take anywhere between a few seconds and annoyingly large amounts of minutes) * optionally figure out how to not receive the whole traffic of the ML or set up custom email filters * figure out if you have to CC the people responsible for the area of the code you're going to send a patch for (which might be written down in a wiki, some CONTRIBUTING file or somewhere else) * figure out if the project wants an extra cover letter for the patch series or not (and optionally search the man pages for how to write one).

With GitHub, I just use [hub](https://hub.github.com/) or an Emacs package or plugins for other editors to

* fork the repository * (without additional tools, I now have to add my newly created remote) * push to my own remote * create the pull request after reading CONTRIBUTING

which so far has been the exact same workflow for every project I've seen (ymmv of course).

Re: Python moves to GitHub

#108

Post by [deleted] »

tracker1 wrote: post #104
carussell wrote: post #97

Earlier quoted context omitted.

SSO is a separately solvable problem, and even so, I'm not sure it's a solution that needs applying here. It's not clear why any form of sign-on is needed—SSO or not. Almost everybody in this space is already using public-key crypto for authentication.

But not for signing into the website, and adding notes for a pull request, or filing a bug/issue/feature request.

[deleted]

Re: Python moves to GitHub

#109

Post by carussell »

tedmiston wrote: post #103
carussell wrote: post #96

Earlier quoted context omitted.

Something else that's IMO more important than any of those items is this: You can't submit patches. Submitting/accepting a patch is something that straight up cannot be done on GitHub. Unless you use a sidechannel like sending a message containing a link to a patch that you threw up on some host somewhere (in which case, have fun rooting out that information on a case-by-case basis), the only way to ever get any chan…

Is that really any different than GitLab though...?

The number of times that GitLab was mentioned in my comment or those upthread in the parent chain: 0.

Re: Python moves to GitHub

#110

Post by carussell »

geofft wrote: post #101
carussell wrote: post #96

Earlier quoted context omitted.

Something else that's IMO more important than any of those items is this: You can't submit patches. Submitting/accepting a patch is something that straight up cannot be done on GitHub. Unless you use a sidechannel like sending a message containing a link to a patch that you threw up on some host somewhere (in which case, have fun rooting out that information on a case-by-case basis), the only way to ever get any chan…

That third "copy" is a copy-on-write copy; it shares objects with its source. (In fact if you built a distributed version of GitHub, you'd have to figure out a more clever solution to this.) It is true that the inability to submit a PR without a local clone is annoying. For the use case you describe, a one-line fix, note that GitHub has a web-based editor (that will create a fork if necessary), so you can skip the lo…

Another mild annoyance: that any time this is brought up, people think that it's relevant to clarify whether GitHub is performing a genuine copy or just simulating one.

> For the use case you describe, a one-line fix, note that GitHub has a web-based editor (that will create a fork if necessary), so you can skip the local branch entirely.

And you've just optimized out the wrong thing.

Person A: "The thing I don't like about going to that place is that I have to spin around three times, go outside, scratch the belly of the cook across the street for ten seconds, and then I come back and place my order and my food shows up."

Person B: "When you go there, you can just do the spinning thing and scratch the other cook's belly and then go home. You don't have to go there to eat."

Oh, Thanks!

Post reply on HN