GitHub kinda sucks
laurent.bachelier.name
laurent.bachelier.name
First, GitHub isn’t that bad. I was tempted to go away from it completely, because of reasons I will explain below, but it does a simple job and does not screw up too much.
It’s fairly slow and unreliable, especially compared to my cheap server (Roubaix, while located in the Far North, is after all much closer to me than the United States). Yet, most of the time it does its job and does not bother me. Creating a new repository is annoying, though after years GitHub developers finally realized the page had to be accessible in more than one obscure way, compared to just pushing to my server (thanks to a Gitolite rule, it creates the repo automatically). git-daemon and cgit are fast, but GitHub sure would handle heavy load better than my server.
The fact that GitHub is insecure and use stupid frameworks isn’t the issue either. It’s hard to miss rogue commits since it means non-fast-forward push, and PGP signatures are the real solution for authentication. I don’t care if they have proper backups either, I have mine: I now push to my server directly, which then pushes to multiple mirrors (this is easy to do with gitolite).
The real issue is mostly GitHub refusing to acknowledge one size does not fit all, and a lot of obnoxious GitHub users.
My biggest issue is “pull requests”. The thing is, you can’t disable them. You can disable issues, wiki (and I do, since they pretty much lock you to GitHub; you don’t own the data anymore like you do with git), but not pull requests. It already has been explained by other people ([1] and pretty much all other PRs, [2]), and probably better than I will. The reaction of GitHub developers was, roughly, “Linus is wrong“. I’m pretty sure the opinion of the creator of git, and the manager of one of the biggest software project ever, isn’t all that wrong.
As a manager, pull requests are annoying, because they require you to add a remote for every user sending a PR. Even for a 2 line patch from an user that will contribute once. The remote URL isn’t displayed straight on the PR, of course. Actually, I learned you can get a patch by adding .patch to the URL, but it isn’t advertised anywhere. Maybe some GitHub developer actually has sense and snuck that feature in. Or of course you can merge the commit from the web. Seriously, you can merge it, without even getting it on your machine (to, you know, test it, read it, etc.), from your web browser. That’s stupid, right? Well, it’s even worse: it makes a silly merge commit, even if it is fast-forward.
As a contributor (and this is the part that wasn’t covered by the other critics), pull requests are even more painful. GitHub projects usually expect pull requests, and only them. So you have to do it the GitHub way: “fork” it (from the web), commit, push on your repo, and make the pull request (from the web). The web interfaces are, as most of them are, slow and annoying. Pull requests are from a branch to a branch, so you have to create a branch if you want to continue working on it without updating the PR automatically. Since I tend to do a lot of small contributions, it spend more time fighting with GitHub than actually altering the code. On sane projects, you send a patch to an e-mail address. Two simple git commands, and you’re done. Oh, and there’s no way of attaching files to GitHub issues, so don’t think about it.
When the pull request is closed, you don’t receive anything. No notification, no mail. There is no way to list your past or pending PRs (or issues).
To sum up, GitHub restricts your workflow, while git is all about flexibility.
The last issue is GitHub users. It’s not much of a pain because it’s easy to ignore them, except being on GitHub could make you likened to them, like having a MySpace page kind of makes you lame too.
Poor commit messages, custom smileys (even in commits!) and unfunny tired memes. A lot of discussions look like there are two intelligent people, and ten others “me too” trying to look good. A lot of projects seem to spend more time advertising themselves than actually trying to work. At least they’re publishing code?
Project forks and watchers mean nothing. Some people will “fork” projects before having done anything, and will likely never commit on it. Yet, it will get listed. Watchers do not mean potential contributors either, or even… users.
I heard some people actually pay that much for sub-par git hosting. I think it tells something about GitHub users.
GitHub could listen to the critics of pull requests, or just acknowledge other ways of contributing, but I doubt it will happen.
Additionally, the article is from 2012.
> for those of you who are too hipster
Is because on mobile, this article instantly redirects to a site that says no hipster allowed, so this comment is the only way to view the article.
Personally I am well versed in git and I don't need GitHub's hand-holding, so I do bristle a bit at things like the GitHub client dumbing everything down. But on the other hand, GitHub is an incredibly powerful and utilitarian web interface to git. Sure git format-patch and am provide more workflow flexibility than PRs, but there is huge added value of having a nice in-line discussion for code review with cross-referencing and all the rest. Dealing with branches and remotes is really not nearly as onerous as the author makes out because git makes it very easy to deal with these things quickly, and you can make it even quicker with a little bit more porcelain like hub (https://hub.github.com).
I don't agree with this. It's actually quite useful. Each time a pull request is opened Travis CI runs the tests and shows green or red for passed/failed tests. So you don't even have to fetch from remote and run tests locally.