Why do some open source projects not accept pull requests, but require contributors to email patch files only?
e.g. Git
Although they publish code in github or other distributed scm hosting.
It is not interactive nor convenient to send patch files.
Patch file is an old-fashioned way.
Pull requests are interactive. Other people may also discuss.

Looking up what "pull request" is (never used git and it's not common to all SCM), it seems that you say, "Hey, I gots me a change over here!" Others can then grab it from you if they wish and review it. Does this work if you go offline? If not, that would be a great reason to prefer patch emails.
–
Crazy EddieMay 18 '12 at 16:27

@CrazyEddie: github sends (or can send) an email to project maintainers when a pull request is submitted. That email contains the pull request description, plus list of commits and changed files. Obviously you have to be online to receive that email and grab the commits, but that's true for patch emails too.
–
John BartholomewMay 18 '12 at 17:11

github throws away all the relevant information, like having even a valid email address for the person asking me to pull.
The diffstat is also deficient and useless.

Git comes with a nice pull-request generation module, but github instead decided to replace it with their own totally inferior version.
As a result, I consider github useless for these kinds of things.

It's fine for hosting, but the pull requests and the online commit editing, are just pure garbage.
I've told github people about my concerns, they didn't think they mattered, so I gave up. Feel free to make a bugreport to github.

He details:

In order for me to pull from github, you need to:

(a) make a real pull request, not the braindamaged crap that github does when you ask it to request a pull:

real explanation,

proper email addresses,

proper shortlog, and

proper diffstat.

(b) since github identities are random, I expect the pull request to be a signed tag, so that I can verify the identity of the person in question.

I also refuse to pull commits that have been made with the github web interface.
Again, the reason for that is that the way the github web interface work, those commits are invariably pure crap.
Commits done on github invariably have totally unreadable descriptions, because the github commit making thing doesn't do any of the simplest things that the kernel people expect from a commit message:

no "short one-line description in the first line"

no sane word-wrap of the long description you type: github commit messages tend to be (if they have any description at all) one long unreadable line.

no sign-offs etc that we require for kernel submissions.

github could make it easy to write good commit messages and enforce the proper "oneliner for shortlogs and gitk, full explanation for full logs".
But github doesn't.
Instead, the github "commit on the web" interface is one single horrible text-entry field with absolutely no sane way to write a good-looking message.

When challenged on the text area for commit messages:

@torvalds The GitHub commit UI provides a text area for commit messages.
This supports new lines and makes it easy to do nicely formatted commit messages :)

No it doesn't.
What it supports is writing long lines that you have not a f*cking clue how long they are.
The text area does not do line breaks for you, and you have no way to judge where the line breaks would go.

In other words, it makes it very hard indeed to do "nicely formatted commit messages".
It also doesn't enforce the trivial "oneliner for shortlog" model, so the commit messages often end up looking like total crap in shortlogs and in gitk.

So the github commit UI should have

separate "shortlog" one-liner text window, so that people cannot screw that up.

some way to actually do sane word-wrap at the standard 72-column mark.

reminders about sign-offs etc that some projects need for project-specific or even legal reasons.

or the short version; he/she who owns the project can run it however they want. If they insist on snail mail hard copy of changes then that's the way you have to submit it (as retarded as that would be).
–
Ken HendersonMay 19 '12 at 0:48

If the commit does not fulfill the project owner's requirement, he can cherry-pick and then amend the commit to what he want. It is important to treasure any contributions made by any other developers. It is a pity if the project owner simply rejects the contributions just because of the non-fulfillment of commit format.
–
linquizeJul 1 '12 at 8:56