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