Technically, no. But how many projects out there would accept an email patch? They'd probably reject it and tell you to issue a Pull Request instead.
I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo.
Mercurial works with email patches. Not only would they accept it, that's the only way to contribute, sending emails to mercurial-devel.
> They'd probably reject it and tell you to issue a Pull Request instead.
Obviously you're supposed to use the project's workflow, but the point is nothing prevents you from setting up a patch model with a DVCS. Quite the opposite in fact, both Git and Mercurial have facilities for automatically formatting and sending patchsets, and for applying trucktons of patches.
Ref: git am, git format-patch, hg export, hg import and hg email
That's more a social issue. How many projects accept patches that go against their submission guidelines? Or coding style guidelines?
> I think his greatest argument is comparing the steps of contributing to github vs contributing to an svn repo.
I found that particularly weak.
Let's look through them in more detail.
1. Get a copy of the source code
2. Make your change
3. Generate a patch with diff
4. Email it to the mailing list
5. Watch it get ignored
And often enough, you simply don't have access to the svn repo to do step 1.
1. Fork the repository on GitHub
2. Clone your fork of the source code
3. Make sure you’re on the right branch that upstream expects your patch to be based on, because they totally won’t take patches on master if they expect them on dev or vice-versa.
4. Make a new local branch for your patch
5. Go ahead and make the patch
6. Do a commit
7. Push to a new branch on your GitHub fork
8. Go to the GitHub UI and create a pull request
9. Watch it get ignored
3. applies to SVN projects too.
4. is optional (though highly recommended)
But it gets really interesting when you want to do a second, separate patch. Do that svn when you can't commit directly? well, either throw away your first set of changes, or make a complete copy of your whole checkout.
"Submit a patch" is open source's way of telling you to fuck off.
The Github business of creating a whole publicly visible fork just to submit a patch is a bit much. I have some obsolete forks on GitHub which I need to kill off so someone doesn't try to use them.
I'm agree with the author that the Github model of "always fork the repo public" is stupid. Why not simply push to the official project repo and (for unauthorized people) let it show up as a "pull request"?
I think the name of the tool is git pull-request.