|TL;DR:||My Argh library has been moved from Bitbucket to Github.|
I’m hosting my Python stuff at Bitbucket since early 2009 (with the oldest repo created on 2009-02-20).
Bitbucket is a great alternative to Github: it provides unlimited free private repositories (including sanely defined conditions for teams); it supports both Mercurial and Git. Pull requests and many other features popular on Github are also present. Why would one want to move from this excellent SaaS to another one, equally non-free?
Two things: Community and CI.
Github is no doubt more popular, even being inferiour to Bitbucket is some aspects. Maybe because it was the first Google Code killer; or maybe because Bitbucket was a “github for Mercurial” until it became clear that Git was the choice of the majority and the niche was occupied. I don’t think features or usability matter that much.
A popular code hosting service means a huge community.
There were cases (definitely more than one) when people would register on Bitbucket only to file an issue; who knows how many times they simply wouldn’t bother to register. Also, their contributions were of lower quality because they were unfamiliar with the site and the VCS. They could add a pull request but they failed to figure out how to do it and simply posted an issue (hopefully with a patch).
Bitbucket is by no means a marginal service. Nevertheless, by hosting my active projects there I prevented them from receiving a certain amount of care from the community. It is also possible that some developers simply missed them while searching on GH.
This was actually the migration trigger for me. I was waiting and waiting for an adequate CI solution available for Bitbucket. A simple solution that just works, you know. And that’s free because I’m not going to pay for such a service if its sole purpose is to test software that I support without any monetary profit (haven’t got not a single cent, actually — and never tried).
The only thing that I could find recently for BB was drone.io. It’s fine but makes little sense for me because the Python version can be specified in project settings, period. You can test against py26 OR py27 OR py32, etc. But what I need — and why I need a CI in the first place — is something that would ensure that my commit passes all tests in all environments that I’m willing to support. For example, Argh must be continuously tested against py26, py27, py32, py33 and pypy. I could run tox locally but it’s very slow and still allows a certain degree of machine-dependent floating bugs.
So, having Travis CI freely available for any repo at Github was enough to finally convince me to move.
Mercurial vs. Git
I’ve been using Mercurial for five years. Yes, I did try Git. And again. And then again. And all the time Mercurial was flat out better: easier and more intuitive, or at least good enough. This was my major point re I-dont-wanna-even-touch-that-github.
My new job, however, required me to use Git. At some point I tried HgGit but it was a disaster. So, okay, let’s play this Git game. Why not. Aaand, well, I like it. Mercurial has indeed a much better UI: more concise, more intuitive (this doesn’t really depend on experience), better thought-out. But Git’s staging area and light branches are very practical, and when you come back to Mercurial, you miss them much more than Hg’s CLI in Git. By the way, Git’s enigmatic and cumbersome interface can be partially “fixed” by aliases:
unstage = reset HEAD -- last = log -1 HEAD
To sum up:
- Git is quite OK, just like Hg.
- Github is quite OK, just like Bitbucket.
There’s probably no need to move my rather popular and stable projects like django-autoslug: the community has already helped to polish the library and has it in bookmarks. By moving the code to another site I would only break people’s bookmarks and confuse them. There would be not much profit from CI either as the code has stabilized and it is highly doubtful that any significant changes are to be expected any soon. So old stuff stays where it is regardless on how popular it is.
Most private projects won’t profit from public interest and don’t need testing anywhere but on my own machine(s). So they stay, too.