> 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.
> 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.
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.
You couldn't just remove the Pull Requests and Issues tab. You'd need to replace it with something detail the alternate contribution workflow.
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.
> You'd need to replace it with something detail the alternate contribution workflow.
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.
> 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.
> Likewise there's nothing stopping you applying an emailed patch in your local copy and then pushing to github.
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).
That's something that github could easily add, given their current level of resources. The million dollar question is "why haven't they added it?" There are at least two possible answers: not many people have asked for it, or to increase lock-in.
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.
> There are at least two possible answers: not many people have asked for it, or to increase lock-in.
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.
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.
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.
Actually, you can commit from github. Go to any file and hit Edit at the top right. It's a single file editor, so don't expect much out of it, but it is conceivable for someone to contribute without using git.
And to your point, you cannot add files via github.
That's exactly what I thought. Whats all that talk about it not being compatible with git and a separate protocol? It's just plain git, you could still apply a patch received my email locally and upload it. It seems to be a lot of whine and very little suggestions. I remember seeing Linus Torvalds writing that it is one of the best options for hosting git, even though he was not a huge fan of pull requests either.
I wholeheartedly disagree. This is like complaining about the mars mission saying that their pictures are not HD enough and they could do better. No they couldn't and they would if they could.
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.
By that measure, as long as a company stays busy on their product, they've built the best product they could.
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.
I see your point, I'm not saying that GitHub isn't awesome. I love it and I am really convinced that it has revolutionized the way collaborative projects work. That doesn't mean it can't be better.
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.
They could start by treating users like they own their projects. There is no way to remove the Pull Requests tab. This is, or at least would have been, trivial to implement. It stems out of the idea that users can't make decisions for themselves. You can listen to 5by5 podcasts 10 hours a week to convince yourself that this is the right way, but from a user empowerment perspective, it isn't.
He may be exaggerating, but what he is trying to say is that he rather not invest in a tool/platform whose product development is out of his control and may be on a path contrary to what he wants out of said tool.
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.