Likewise there's nothing stopping you applying an emailed patch in your local copy and then pushing to github.
This post seems to be making a mountain out of a molehill.
GitHub pull requests are made to be compatible with 'git am' on the command line and is documented in the GitHub "Using Pull Requests" help article under the heading "Patch and Apply":
http://www.wired.com/wiredenterprise/2012/05/torvalds_github...
> Torvalds says he brought up his problems with GitHub’s creators, but “they didn’t think they mattered.”
This is the crux of the problem. GitHub spends a great deal of resources working on a mac app and a windows app, which aren't interesting to people who do things the UNIX way at all. Meanwhile support for a good git workflow falls by the wayside.
It would be a substantial improvement if you could just remove the Pull Requests tab, along with the Issues tab.
I don't think you understand what github is and what their goals are at all. Besides that this is bad "zero sum game" thinking.
Hint: UNIX nerds that use mutt and are perfectly happy with the standard git command-line client and using send-email or am are already served. They don't need and clearly (proven by your comment) don't want github all. Yet people clearly love github and many use the mac and windows clients. Many non-programmers are even using github for things that aren't even (entirely) code projects.
If you don't want to use pull requests or issues, just state in your README under "how to get your changes merged" and "where to log issues" what people should be doing if they want to collaborate on your project.
Also quick ignorant question: Does the diff patch approach eliminate the need to fork a project to contribute to it? I like the idea of forking for a project I plan on contributing a bunch to, but when I just want to contribute a bug fix or some tests, I find having to fork to be completely unnecessary.
Yes, it would be closer to an equivalent workflow if the the project owner would mention it in a README. But savvy users could send a nice patch email using only instructions in the git man pages (man git has a list of commands).
> Also quick ignorant question: Does the diff patch approach eliminate the need to fork a project to contribute to it? I like the idea of forking for a project I plan on contributing a bunch to, but when I just want to contribute a bug fix or some tests, I find having to fork to be completely unnecessary.
It does. It's quite excellent being able to do a one-off patch.
That alone I think is an excellent reason to support this feature and a much stronger argument than "Pull requests aren't native to git". I really wish submitting one off patches didn't require forking.
Right. Now let's say you are the one not using github (you use raw git), and you want to send a patch to somebody using github ("not git"). As TFA notes, either nothing gets done (you send-email and the other guy just doesn't see/want it) or something has to give, you have to create a github repository with the result of your patch or the other guy has to learn git-am.
That could be fixed if github had better mail integration (and more generally more hooks for standard git behaviors) and you could essentially create a pull request by git-send-mail-ing some sort of special address @github. And the pull request got its own mail thread (so the initial sender got replies & al without needing to go on github).
As far as I know, that's not the case.
It's a feature that github SHOULD add. There are some people who want it, and these people are the type of people that can become quite vocal proponents or detractors.
More importantly it signals quite strongly that github intends to become a good citizen in the nation of git rather than trying to appropriate it.
Watching Zach Holman's various presentations on Github and how they work interally provides a third one: since Github uses pull requests internally (and new githubbers are probably github users in the first place) nobody has any issue with not supporting `am` and `send-mail` there, so nobody went and built support for that.
Or you know he checks his email and takes the patch. When you use github you are using git. There is no way to commit from the github website, so if they have code on github then they must have interacted with git. Now that we have established they interact with git then they have the capability to interact with the patch feature if they so desire.
And to your point, you cannot add files via github.
Well since I'm already downvoted I'll just finish this rant. Comments like this frustrate me, why would you just assume something could be done better just because it is easy to do? Everyone read how Github works, it's a collective of programmers that assign themselves tasks, anyone at github could for themselves decide to implement this feature. No one did, obviously they've got something better to do! Don't tell me every employee at github is an evil corporate overlord that wants to vendor lock the world into github.
They make the best source control repository in the world, and you should unequivocally laud them for that.
Frankly if you don't, I think you're a bit of a retard, so that brings me to the linked article. It makes no sense at all. Github does nothing fundamentally wrong, and it is not incompatible with how he or anyone else uses software.
If a project requires you to submit a pull request via github, how is that different from a project requiring you to submit a bug through mozilla? It's just not. If you think you and your patch are so important you shouldn't be bothered with pull requests, why don't you just fork and put it on a repository somewhere else?
As if e-mailing patches to people is somehow more effective at getting them to merge code. As if git am is somehow a fundamental property of git, instead of just some feature Torvalds hacked onto it.
I would like to rant about more invalid points he makes about github being a 'reimplementation' of git, but he doesn't make any other points.
That sounds like hippy hand-wavy BS to me.
As a software engineer who works at a Bay Area startup with a pick-your-own-tasks model, we still (like GitHub) have product managers who give input and direction into features and product design. Just saying that the decisions they've made about how to allocate resources are the best possible decisions they could have made is just giving them (or anybody else) too much credit.
Being a distributed version control system, Git supports different workflows. Pull on demand is one of them, but mailing patches is an equally valid option. Git was initially conceived with the kernel's particular workflow in mind, and `git am` is fundamental in that process. Do I find it as easy to use as what GitHub offers? No, but supporting it wouldn't hurt and it would bring some old-school developers to GitHub's side.
GitHub provides a lot more than the open source tools. Primarily it provides community. Most people would rather not have patches received by email. They would prefer a web-based interface where you can comment, adjust, and accept.
This is a classic case of not getting it.
You can manage your repo independently and push to GitHub when required. It's not even hard. If, as an open-source developer, you want me to log into your own personal bug-tracking system, your own personal source-control system, you've lost me as a contributor.