> 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.

Fossil [1] repositories include a distributed bug tracker (and also a distributed wiki and a distributed time-based notes system), and provides a browser-based UI.

I've only read about it, not played with it, so don't know how close it comes to what you are envisioning.

[1] http://fossil-scm.org/xfer/doc/trunk/www/index.wiki

It's a good idea! However, the distributed nature seems to make it sufficiently involved as to preclude a good UI (e.g., issues seem to use hashes), and the simple fact of not being git, regardless of whether it's better than git, is a serious problem for adoption. Bitbucket also learned this the hard way, and even made an April Fool's joke about it before realizing they had to primarily support git.

GitHub being centralized is a feature, not a bug. You don't have issues that exist in some people's repositories and not others. You don't have a question of who has the authoritative repository; either GitHub does, or GitHub doesn't and there's a note saying it's not authoritative. You can support things like have cross-site forks, but it's actively good for UX to have a single authoritative server for the current state of the project. (And you certainly don't want to require cross-site forks, since that would make it far more burdensome to submit a single patch.)

> and the simple fact of not being git, regardless of whether it's better than git, is a serious problem for adoption

I think I was a bit too terse. I didn't mean to suggest that someone who wanted to do everything (SCM, bug tracking) distributed use Fossil instead of git. The idea was to use git for the code, and Fossil for the bug tracking and wiki.

Fossil is so great... only if they picked branding that doesn't mean "something from the far past"...

Like GitLab?

GitLab and gogs are both fine for getting 80% of the UI, but there are network effects with GitHub: that you're already signed in and have keys and such set up (although OAuth and API cleverness with keys can get you close), that your contributions across all projects show on your profile, that third-party tools like Travis know how to talk to your GitHub in particular, etc. And all sorts of little things, like that when you mention another project's PR in a commit, a note shows up on that PR. That's a lot of what makes GitHub nice to use, more than just the UI, and I suspect that's what pushed some of the Python core devs in favor of GitHub.

There's potentially a way to build a system that federates all of this, and then toss GitLab on top for the UI. A good standard would be whether a newcomer could submit a PR with only one more click (for the OAuth screen) than they would need on GitHub.

A good federated system would allow a fork from one host to end up on another and the PR would be done automatically after the very first PR was done with that extra click (and that extra click should do a bit of magic behind the scenes to send your key over to the other server together with your first sign-on on that server).

That way future interaction would hide the fact that the systems are in fact separate.

Also, Gogs. Still, I stick with GitHub over either of these two others.

Good point, gitlab is probably 90% there already.

Is GitLab federated?

Not really.

Like Phabricator?

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 changes upstream is via pull request. Mildly obnoxious, but then you get hit with this zinger:

You can't submit a pull request if your branch isn't already hosted on GitHub.

So if you want to make a one line fix, there need to exist no fewer than 3 copies of the repo: the upstream, your local copy that you made when you cloned it, and then some third copy that you have to spin up and maintain through GitHub. This is nuts.

I highly doubt GitHub maintains two copies of the same object (not counting replication). They likely copy most of the repo metadata for forks, but if two objects have the same SHA, even in completely different repos that were never even forks of each other, they can just store one copy. You can see evidence of this if you look at some of their advice for how to remove all traces of some data (say, you accidentally checked in sensitive info to a public repo and now need to make it totally inaccessible)

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.

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!

OK, sorry, can you clarify what you are actually objecting to? I'm not quite understanding what the workflow you desire is -- you have a patch generated locally, and you want to submit that. What happens if it doesn't apply cleanly? Should it be rejected, or should it give you an option to fix it up, or?

I hope it's clear from my example that it's the twirling and belly-rubbing that I could do without.

> I'm not quite understanding what the workflow you desire is

It's easy. Look at how most open source projects work literally anywhere, outside of GitHub and its clones. Look at how Mozilla works. Look at how Chromium works. Look at how the patch-based workflow that LKML uses works—using Git, no less. Look at virtually every open source project that existed before GitHub showed up worked for decades.

My objection is this:

> third copy that you have to spin up(1) and maintain(2) through GitHub(3)

This is how it should be: I have a file containing my changes (a patch) that I can send to you (the maintainer). That's it. That's all that needs to happen.

To really belabor the point, here's a comparison of the two processes: I clone it. I change it. I create a patch. I send it in. (Replace the first step with `git pull` if this isn't your first contribution and you still have the repo around from last time.)

Here's how it works on GitHub: I clone it. I change it. I dick around in the GitHub UI to fork it and wait. I add that new fork to my remotes. I push it. I file a PR. I dick around in the GitHub UI some more to get rid of the zombie repo, but only after my changes have been merged. (Replace the first step with `git pull` if this isn't your first contribution and you still have the repo around from last time. Skip the last step and step 3 if you think you might ever contribute again and would like to minimize the hoop-jumping you have to go through for your next contribution. Omit step 4 if both of the preceding conditions were true.)

Astute readers will point out that you can completely skip the remotes step if when you make your original clone, you do so from your personal fork, rather than from directly upstream. These astute readers are not as astute as they think. Notice how much of "the GitHub way" requires knowing all the things that you would possibly want to do far before you actually want to do it. At the very least, it requires that you preemptively create a fork for every project whose source you pull down, on the off chance that you might want to contribute to the project some day. (Of course, nobody does this and ends up just messing with their remotes instead, but they're no less happy to show up and point out that it can be done, while generally ignoring its unreasonable requirement of premonition and offer no response.)

> What happens if it doesn't apply cleanly? Should it be rejected, or should it give you an option to fix it up, or?

The question is weird. Just do what Git does. It already supports patches. There's no design decision to make here.

This is why there's a problem with characterizations of the sort you'll find below—you get people who've never even used Git or any other sane VCS outside of GitHub that come along and try to tell you about how things work. They'll say that GitHub is Git with some extra features. No. GitHub is a crippled implementation of Git with some proprietary value-add to halfway work around the stuff that it screws up.

And let's be clear. I know why it screws those things up. It's for the same reason Facebook makes all the moves that they do to aggressively silo themselves. By both deprioritizing support for patches and disallowing off-GitHub pull requests, and by championing a more convoluted workflow, they end up not only with the upstream hosting their repo there, but also with virtually every contributor hosting there, too.

The weird thing is that with Facebook, you run into a vocal minority whose response to that behavior is to say, "fuck that, and fuck them", and the FLOSS crowd generally shares membership with that group. Meanwhile, GitHub—whose userbase is largely made up of only that type of crowd—seems to deal with far less criticism over it.

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.

That's not what the original article is about, either. They're not leaving GitLab. They were never there.