(This is a grumble. You've been warned.)

A lot of open source projects are hosted on Github these days and many of them prefer to get patch submissions in the form of Github pull requests. On the one hand I admire Github for making the process of pull requests relatively painless for the maintainer(s) in my brief experience. On the other hand, I don't find pull requests to be very attractive from the other side, as a (potential) submitter of changes, and I suspect that a lot of other potential change submitters are going to feel the same way.

In the moderately old days, submitting changes was really easy. You started with a current, checked out copy of the project's source repo and you carried your relevant changes on top of it as uncommitted changes (in a CVS or SVN based project you didn't have any choice about that and in general it was usually the easiest approach). When you wanted to submit your change, you ran '<whatever> diff' to get a unified diff relative to the latest master, dumped the output in a file, and emailed the result off to the project with an explanatory note. If you were running your modifications yourself, you could do this from your live working repo.

Creating a Github pull request is not so simple in practice. As far as I can tell, the workflow I'd want to use is something like the following:

• fork a copy of the project into my own Github account.
• 'git clone' that copy to a scratch repo locally. Create a new branch in the repo and switch to it.
• 'git diff' my working repo with the uncommitted change then use patch to apply the diff to the scratch repo.
• 'git commit' my change in the scratch repo (on my branch) and push it to my Github fork.
• go to Github and submit a pull request from my Github fork to the master.
• after the pull request is merged, delete my Github fork and my local scratch repo.

If I was being thorough, I should actually build the project out of this scratch repo and maybe do a test install (even though I've already built and installed from my working repo).

I have no idea what I'd do to keep clean commits if the master repo moves forward between my pull submission and when it gets merged. Maybe Github manages this transparently; maybe I need to update my scratch repo, 'git rebase' to get a new clean commit (maybe on a new branch), and push it back to Github to make a new pull request. It's a fun new frontier of extra work.

(None of this is difficult with the 'email a patch' approach. You 'git pull' to update your working repo, maybe fiddle with your change, then send another email with a newly generated 'git diff' if you think you need to or get asked for it.)

Note that there are some simplifications to this that could be done if I contributed a lot to specific projects, which is what I suspect Github pull requests are good for. But I rather feel that they're not so good for essentially one-off contributions from people, which is the category I'm most likely to fall into. So I'd sure like it if Github based projects still made it easy to send them patches by email (and mentioned this in any 'how to contribute' documentation they have). Unfortunately patches by email don't integrate very well with Github issues (of course), while Github pull requests work great there. I'm sure that this is a not insignificant factor pushing projects towards pull requests.