It used to be that GitHub vs. BitBucket was a no-brainer. GitHub was sleek, featureful, popular, and supported git, the godsend.
BitBucket was clunky, buggy, comparatively little-known, and required you to use that hg thing with the annoying workflow.
However, as time has gone on and Atlassian has continued to work on BitBucket, things seem to be shifting in BitBucket’s favor. BitBucket has added support for git, offers private repositories in their free tier, and continues to make minor improvements every now and then, while GitHub seems to be backsliding.
Oh, GitHub still looks nicer by a mile and continues to improve on that front, but what you can do with it and how you communicate are backsliding (and communication is the whole point of the thing). For example, in recent months, GitHub has:
Killed off the private messaging system
GitHub claims that, by killing off their private messaging system, they’re serving us better by giving us one less inbox to manage… yet I still obsessively go into GitHub every few days to flush out the pointless “GitHub Pages built successfully” messages and duplicates of bug notifications that pile up in the “notifications” inbox.
(And the only button that applies to everything is “mark as read”, so I manually have to click every single entry to delete them… including a page reload after every ten clicks.)
Couldn’t they just have ditched both web inboxes, kept the PM form, and forwarded all messages directly to my primary e-mail address for handling?
Forcing me to expose my e-mail address to the world if I want to be reachable and forcing me to abuse the issue tracker to communicate with like-minded individuals is so bass-ackwards that it makes SourceForge seem superior!
Update: GitHub now supports only receiving notifications via e-mail, but they still haven’t provided a replacement for the PM form’s old status as a spam-proof, guaranteed-to-be-there way to contact another user.
Started requiring that user.email actually be an e-mail
At first glance, this may seem reasonable… except that git itself doesn’t enforce that constraint and git is famous for not letting you rewrite old commits without breaking push/pull with everyone else’s branches.
What makes it even worse is that, since GitHub used to support it, who knows how much data was submitted which once was valid and now isn’t. Smart move, guys.
I don’t know about you, but I’d rather give up having my commits hyperlinked to my account (or, even better, just switch to BitBucket, which still allows arbitrary strings) than leave a genuine e-mail address lying around where every spambot in the world can find it.
I’ll be sticking with http://www.ssokolow.com/ContactMe as my commit ID’s “e-mail address”, thank you very much.
Replaced their blog comments with Twitter
As Christian Heilmann elaborated on, Twitter is not a discussion platform because its character limit kills nuance in discussion, it has no threading, and its structure makes it nearly impossible for anyone but the author of the blog post to gauge community reaction.
If I find news sites without comment systems unsatisfying and/or distasteful enough to avoid them, I’m not going to be very enthused about a “Web 2.0” code-hosting site that does the same with their public announcements. I don’t care whether it’s spin-doctoring or just laziness. (Again, if I wanted the latter, SourceForge has it in spades)
So… BitBucket
So, these days, what exactly does BitBucket do wrong, aside from losing the network effects battle?
Surprisingly little from what I’ve been able to tell… they just made some bad choices in what they did wrong:
No GitHub Pages Competitor
Most of the time, when people host a project, they actually care about getting potential users interested in it. That means they need to host screenshots and logos and possibly even JavaScript demos so they can make a good first impression. It also means they probably want to give their project a memorable look and feel. Wikis, issue trackers, and repository browsers don’t do that.
I’m told BitBucket has support for a per-user Pages equivalent, but that’s not really a big help (It took me ages to find a use for GitHub’s per-user Pages support but I was using per-project pages from day 1) and it’s so under-documented that, despite looking for it, I spent months not knowing it existed. (BitBucket’s opportunity to be worse than SourceForge)
If I’m going to have to pay for site hosting anyway, I might as well just host my own git repository and bug tracker while I’m at it and gain more customization support.
Poor First Impression for Project Pages
With no equivalent to GitHub Pages, the full burden of making a good first impression falls to the project pages. Unfortunately, they are also in need of some TLC.
First, they still knock-off GitHub’s old theme, which now feels five years out of date. Not a good first impression to make when the projects you compete against for attention are probably hosted on GitHub.
Second, the default configuration for a project’s landing page shows off their most recent commits and their README file. The problem is, in my experience, there are three pieces of information, from most to least urgent, that I want to know when I visit a project’s landing page:
- What it’s about. (GitHub and BitBucket both get this right by showing the README.)
- What the license is. (Neither GitHub nor BitBucket support this explicitly, but GitHub’s overview page makes it trivial to see and click on the COPYING or LICENSE file.)
- What language the project is written in. (Same situation as the previous point.)
- How actively developed the project is. (GitHub didn’t used to show the most recent few commits on their overview page, but if the first three are satisfied well, then I have no problem with one click to check the commit log.)
Yes, you can configure your BitBucket repository to show the tree browser as the default, but then it doesn’t display the README, which is even worse.
So where does this leave us?
For now, I’ll continue to use GitHub… maybe with a public e-mail like use.the.mail.form at ssokolow.com which I can make valid only long enough for GitHub to accept it.
However, they’re on very thin ice and, hopefully, BitBucket will wake up, seize this opportunity, and give GitHub enough competition to restore progressive (rather than regressive) innovation to code-hosting sites.
(Seriously, Google Code? You thought it was helpful to remove the project activity overview when the majority of projects on established sites are dormant and possibly buggy?)
Update: While our needs differ on things like the importance of a valid e-mail address, Linus Torvalds also makes good points on GitHub’s shortcomings. Not sure how BitBucket compares though. Probably equally poorly. (A little something that came to my attention via Planet Mozilla)
GitHub vs. BitBucket: Shifting Value Propositions by Stephan Sokolow is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
As I see it, the only reason to use bitbucket at this point in time, is their private repositories, which can be used by up to 5 developers.
It’s a neat feature, although if you get 5 IT people together, I’m pretty sure you’ll find at least 1 of them able to host in his home-server a private git repository… Doesn’t take much is your ADSL ISP is ‘stable enough’ (mine isn’t for example).
Nice post though.
Pingback: Git pull requests (and Github rant) | Some Things Are Obvious
Well, personally, I have both. I don’t care about pages. Most of my documentation is hosted at pythonhosted (logical, if you apps are on PyPI).
What I like about Bitbucket.
– Free private repositories.
– Mercurial (which I prefer over the git). Note, that I intensively use both. Git at work and Mercurial mainly privately.
– Google Analytics integration.
– When you get the repository URL (to clone) it already contains the “hg clone” command. No need to type again. On Github, it’s just a repository URL, to which you always have to prepend “git clone”.
What I like about Github (and miss in bitbucket).
– Cleaner way of always pointing to a file in a branch. For example, I want users always to be able to grab a single file from stable branch using wget. In bitbucket it’s just impossible, since it hard codes the commit number into the path. Github does that part clearly better.
– Ability to see the number of forks and followers on repository level, without going into the repository. On Bitbucket you have to go into the repository in order to see those numbers.
A in general, Git vs Mercurial.
While both a great (compared to SVN or Bazaar), Mecurial is preffered one.
There are several things I badly miss in Git and absense of things make it extremely annoying over time.
– It’s easier to type “hg” than “git” (Mercurial wins).
– There is no “git addremove” command. For those who didn’t use Mercurial, the “hg addremove” just marks all new files as new and all removed files as removed – just one command for both (while you can still use “hg add” or “hg remove”). Git is mostly and greatly annoying for the absense of this. I know, there is a way of doing it with git too. Just Mecurial does it beatifully – with minimal efforts (Mercurial wins).
– Why on earth “origin master”? Isn’t it obvious, that my very first commit would likely go to the master branch? (Mercurial wins)
– When I pull, I don’t want the code to be updated immediately (Mercurial wins).
– Mercurial has a wonderful built-in server. For those why didn’t try, “hg serve” (Mercurial wins).
– In Git, I have to push tags using a different command (“git push –tags”). In mercurial it’s just “hg push”.
There is no single thing I miss in Git when using Mercurial.
So, for myself, I combine those. Most of my repositories are hosted on both. When I need a permanent link to a tagged file (that changes over time), I use Github. For the rest, I use Mercurial.
Interesting. Back in the early days, I found the exclusive Mercurial support to be an automatic deal-breaker.
Here are a few reasons I consider git to be superior:
1. I’ve never heard of a true data loss bug in git (As long as you don’t
git gc, you can recover) but I’ve seen several mentions of people finding ways to trash their mercurial clone so badly that the only way to recover (after googling and consulting with IRC) was to clone a new copy and manually add the changes from their old working copy, losing any commit information in between the two states. (One of which I observed personally, when it happened to the developers of Audacious Media Player. They use git now.)2. Everyone I’ve asked about
git add <existing file>in Mercurial has said it’s “not necessary” and, when I tell them that it’s not negotiable, they offer up some little-known and/or overly complicated way to set up that behaviour.At this point, I pretty much stopped looking. Why should I use a version control system that performs roughly equally to git but lacks the command central to my workflow and might trash my commit history if I stumble across some weird, untested way to use it?
As for the rest of the details you refer to…
1. I’ll admit that the difference between a two-character command and a three-character command is noteworthy… but that’s what putting
alias g=gitin your~/.bashrcor~/.zshrcis for.2. If I understand
hg addremovecorrectly, the git equivalent isgit add -Aand you can make it more familiar by runninggit config --global alias.addremove "add -A"(or, if you use it a lot, you could alias it to something likegit arinstead)(While I don’t mind it, that
git configcommand is another strike against Mercurial for some people. It lets you make small adjustments to per-repository or global config files without having to navigate your way to them and open them in a text editor.)3. I’m not sure what you specifically mean by “Why on earth ‘origin master’?” but I’ll assume you’re referring to what you have to type to set up a new GitHub repository. That has nothing to do with how it handles your commits locally. It controls commands like fetch, push, and pull which need to know which branch on the GitHub server corresponds to which branch in your local copy. (Because Git was designed to meet the needs of the Linux kernel development process, it needs to be able to support some really ad hoc, decentralized push/pull models.)
4. Regarding “When I pull, I don’t want the code to be updated immediately”, again, you don’t understand git properly. The equivalent to
hg pullisgit fetch, notgit pull.git pullis equivalent tohg pull -u. (See WikiVS for a command comparison chart)5. The git equivalent to
hg serveisgit instaweb.Also, Git comes with
git svnbut Mercurial doesn’t come with hgsvn as part of the default set of commands so, by your own standards, I could argue that Git is superior to Mercurial because it can interoperate with SVN servers out of the box. (As long as you’re not using a Debian-based Linux. They split it up into a lot of little packages so you need to installgit-svnfirst.)6. The need to push tags manually is an intentional thing because the people who develop and maintain git often have tags that they only use to keep notes for themselves which aren’t intended to go public.
If you want to override that behaviour, you still can.