19

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.

Improve this question
3
  • 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, 2012 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, 2012 at 17:11
  • Patchfiles are universally supported. Pull requests are vendor-specific. Why would you expect maintainers to accept them?
    – Anonymous
    May 20, 2014 at 14:57

2 Answers 2

Reset to default
18

It depends on who is 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
9
  • 6
    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, 2012 at 0:48
  • 5
    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, 2012 at 8:56
  • 3
    @linquize Open source projects usually lacks man power.Those 'cherry-pick & amend' time could be saved.
    – weakish
    Nov 25, 2014 at 11:38
  • 2
    "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, 2016 at 22:06
  • 3
    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, 2016 at 23:36
1

It just takes time for developers to adapt to new possibilities.

Since this question was asked, github has gained acceptance by major open source project.

github/gitlab has made working together with pull requests a lot easier.

It

  • saves time t
  • to learn g individual contribution guidelines
  • for millions of developers/users (u)
  • who invest time (i) to improve, find bugs and fix them
  • and this repeatedly (n)

The actual productive contribution for projects (independent from github) is uni.

The non-productive bureaucracy time saved through github is utg.

The total effort by the contributors is u(tg+ni). Without the utg, contributors can concentrate on the productive work, i.e. on uni.

If one invests some effort to set up one's machine according the git guidelines (see links below), one can contribute as efficiently using email as with github.

  • But then others don't see the issues and the pull requests of a project. It is important for developers to get an idea about the state of a project and current problems. This information avoids that different developers fix the same issue.

  • Github's value is also that it has become a meeting point for developers. It connects developers via their code. Else it would be harder to find solutions and thus not reinvent the wheel.

  • One cannot link to issues and arguments sent via emails.

github was and is a factor to make people adopt git as SCM. If more use the same SCM, that alone reduces the overall effort.

PS: Some links to do pull requests without the web UI of github:

Improve this answer
1
  • I agree. Upvoted (and thank you for your edit on my answer earlier). Since 2012, GitHub has also introduced recently (2020) discussions (docs.github.com/en/discussions), which can help separate open-ended discussion from pull-request contributions and comments.
    – VonC
    Jan 23, 2021 at 14:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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