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