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.

  • 1
    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. – Edward Strange May 18 '12 at 16:27
  • 1
    @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 Bartholomew May 18 '12 at 17:11
  • Patchfiles are universally supported. Pull requests are vendor-specific. Why would you expect maintainers to accept them? – Anonymous May 20 '14 at 14:57

It can depends on who will be in charge of accepting your pull request.

If it is Linus Torvalds, well... a good old patch is preferable:

I don't do github pull requests.

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.
| improve this answer | |
  • 5
    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 Henderson May 19 '12 at 0:48
  • 3
    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. – linquize Jul 1 '12 at 8:56
  • 1
    @linquize Open source projects usually lacks man power.Those 'cherry-pick & amend' time could be saved. – weakish Nov 25 '14 at 11:38
  • 1
    "writing long lines that you have not a f*cking clue how long they are." Well that seems solved already, now it warns you quite stringently of too-long first line, and has two separate text boxes for short and detailed message. – heltonbiker Apr 29 '16 at 22:06
  • 1
    Linus complains about the github implementation, but that does not mean that pull requests are bad in general. In fact, it is really retarted to send mail patch files instead of using a nice interactive web interface which works directly with git instead of importing/exporting files – Mike76 Sep 15 '16 at 23:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.