I think his refusal to accept from the web interface has more to do with the web interface being so far out of his normal workflow that it would be too disrupti

I think his refusal to accept from the web interface has more to do with the web interface being so far out of his normal workflow that it would be too disruptive for him. If you accept this pull request it might set some sort of precedent then you'd have to shoot down the next one--might as well just stop it in its tracks. I didn't realize all the tools git has built-in (therefore developed with Linus's workflow in mind) for handling patches until I was poking around today: git format-patch origin This creates a git-style patch for every unpushed commit I have. git-style meaning it's actually an email with the log, diffstat, and patch in it. If there are multiple commits the subject of the email will be [PATCH 1/n] <first line of commit>. When you're dealing with many patches a day this gets the point across fast. Better yet: git send-email origin Same thing as above, but it hooks into your system's sendmail and sends the patch email(s) for you. On the receiving end, you've got: git apply --check <patches> You can make sure they'll actually work against your copy before diving in. And most important to Linus is probably: git am --signoff Which can hook into your mailbox and apply all the patches with commit messages and add the Signed-off-by line with your email account. So if your workflow consists of looking at a patch in the terminal, then applying and committing that patch many times a day these things are very important to you and they provide you with the information you need very quickly. Compare that to the point-and-click web interface of github, sure it works at low volumes but when you scale it up it becomes clumsy and slow. I suspect his complaints about commit formatting and quality of github contributors doesn't help are more of the two more annoyances variety.