> 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. That's

> 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. 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 Wrong. You can't generate a diff, unless you first made copy of the original sources, or re-download/unpack it. So there's an essential step missing. 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 1. is github specific. Gitlab and Bitbucket don't require that 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.