One tiny megaphone
This post says it all. So much for having to choose between libre options.
This is also a case where reading the comments is worth it. There’s a very lively debate on the relative merits and pitfalls of “restrictive” and “permissive” open source licenses.
My last post talked about using alternatives to GitHub in order to (in no particular order):
I’ve done a bit more work with two Saas projects that can be used to achieve both goals above: Gitorious and GitLab Cloud. My impressions follow.
Gitorious has been around a long time. I remember considering their hosting and software about the time when Google Code was still really hot (i.e., IIRC, before GitHub was a “thing”; Wikipedia says Gitorious launched in January of 2008 and GitHub in April of the same year). Many well-known and important FOSS projects are hosted on Gitorious.
If Gitorious (the service and the software) were the only option available today, people would be praising it to the nines. It offers repository hosting with decent code browsing, project logging/graphing, project wikis, and an interesting feature that lets you POST stuff to an arbitrary URL whenever a commit is made. The interface is pleasant and generally clear. The software that runs the service is FOSS and easily downloadable. Bitnami even packages a bundle that makes setting up your own service stupid easy.
However, there are a couple caveats. First, compared to other hosting options, Gitorious is a bit short on features. Notably absent are issue tracking and continuous integration support. While there are third-party tools that will do these for you, one of the nice things about GitHub and BitBucket (and, if we limit ourselves to issue tracking only, Google Code and Sourceforge) is that these are part of the service—meaning virtually no setup and good integration with the codebase. Some might actually prefer having orthogonal tools for issue tracking and CI, so this won’t be an issue for those.
The other thing you need to be aware of is that Gitorious organizes repositories based on projects rather than on users. Projects can have multiple repositories in them, but all the repositories will share the the same wiki (i.e., there is no per-repo wiki). Also, the owner of the repo will not be in the URL of the project. In other words, Gitorious isn’t really designed to support a “Here’s a collection of my repos,” Web presence. It’s setup is great if you are deploying a server for internal projects, but it’s not really optimal for being a “social coder.”
GitLab, or more relevantly, GitLab Cloud, is new to me—I discovered it only a few days ago. Indeed, it looks like it’s new to everyone, with late 2011 being the date of the first entry on the company blog.
It seems to me that GitLab is trying to be a feature-compatible alternative to GitHub. Even the names are similar. A GitLab account gets you repository hosting, per-repo wikis, issue tracking, and code review. GitLab also makes a FOSS Continuous Integration product—though I have yet to explore how it integrates with GitLab Cloud. The GitLab Community Edition is FOSS and easily downloaded.
My biggest concern with GitLab is that since it’s relatively new, it might go away. The fact that it’s FOSS hugely mitigates this concern. If Facebook buys GitHub and shutters it, your workflow, community, everything is screwed. But if GitLab shutters, you only need to grab the last release of the software stack, set up your own server, transfer your data to the new server, and update your URLs. As was the case with Gitorious, there is a Bitnami bundle to make setting up your own service brain-dead simple should you need/want to do this. (There’s also one for their CI project). In spite of this, it would be a bit of a drag of they disappeared.
My other concern is that I don’t know how much GitLab’s development will focus on introducing new features not available on GitHub (or elsewhere) and how much it will focus on simply maintaining feature-parity with GitHub. I’d be feeling a bit warmer and fuzzier if they were more aggressively inventing solutions rather than reimplementing GitHub’s offerings.
All said, I think I will focus on working with GitLab to see if there are any unforeseen gremlins. If not, GitLab may become the new primary host for my FOSS work.
Only one of my 20 or so public repositories is currently on GitHub. The remainder are mostly on Bitbucket. I am seriously considering moving my public Git repos to Gitorious.
Why, when everyone and their mother is shoving heaps of projects at GitHub, would you consider anything else? It’s precisely because GitHub has become the defacto standard that I am trying to avoid it. The Git/Github conflation is bad enough (GitHub invented Git, right?), but it’s also disconcerting that Github (a private Saas company) is creating a virtual (!) monopoly in the field. Given that, I think it’s a good idea to support credible alternatives.
I originally started using Bitbucket because they offered Mercurial hosting. This was back when Git support on anything but POSIXy systems was pretty poopy and Mercurial was the friendly, multi-platform alternative. Bitbucket offered features on a par with Github and were quite generous with their no-cost offerings (and still are). Eventually, Bitbucket saw the writing on the wall and introduced Git hosting alongside Mercurial. Later, I too conceded that Git had won the DVCS race and switched to Git as my default DVCS. However, I saw no reason to change where I hosted my public repos—especially in view of GitHub’s growing dominance.
Both Bitbucket and GitHub are private Saas companies that make money hosting private repositories and/or offering additional services. Gitorious is as well but with one difference: the platform that runs Gitorious is FOSS that you can install on your own servers. Which means you get all the Saas perks along with all the great things that go along with FOSS. The range of features that Gitorious has added over the years has grown to the point where I think it’s worth a serious look. I’ll report back when I have more info.
Update: Another worthy contender is GitLab Cloud. It runs on GitLab’s own software—which has an open source version (MIT license). I’ll be taking a close look at that as well in the upcoming days.
If you are using git-gui to manage your Git repositories, you may be perplexed that you can’t find support for tags anywhere. If that’s you, then you might also be overjoyed to learn that tagging support is actually part of gitk, git-gui‘s sister app.
To create a tag, open the repository and branch you want in gitk. An easy way to do this is to use git-gui‘s Repository > Browse xxx’s Files menu items. Then in gitk, right click on the commit you wish to tag (on the actual text, not any labels) and select the Create tag from the context menu.
Once you get that sorted, you might next be perplexed that when you push your repository to the remote origin, tags don’t go along for the ride. That’s because, “By default, the git push command doesn’t transfer tags to remote servers.”
You can remedy this with some command-line foo. I have used the shell command:
$ git push origin --tags
to push all tags in a local repository to the remote.
I’ve finally gotten around to using Git instead of Mercurial on a project. So far it has been uneventful. I still prefer Mercurial because it treats all OSes as first class citizens and because I think the CLI is cleaner. My workflow doesn’t require a lot of branching, but Git fans seem to think it really shines there. My main motivation for going Git on this project is to get some experience with what will likely become the defacto standard DVCS.
I am mostly using git-cola git gui as a GUI frontend. Ironically, git-cola—like Mercurial but unlike Git itself—is Python powered.
The best resource I’ve found so far for working with Git if you already know DVCS fundamentals is Spherical’s “Git for the lazy.” Entp’s “Version Control for Designers” is pretty good too.
I’ve been using Mercurial along with Bitbucket for project hosting for quite a while now. I’ve also grown quite fond of EasyMercurial to help manage my repositories. However, I have started to wonder if I should consider using Git as my defacto standard VCS.
I was originally attracted to Mercurial over Git because I got the sense that Git was an almost hackish amalgam of various scripts written in a variety of languages—and because it encapsulated a lot more “power” (read: “complexity”) than I saw myself needing. And while Linux was (and is) my main OS, Windows support for Git was sorta grimmish. Bitbucket’s hosting policies at the time seemed better than the closest Git-equivalent: GitHub (still do—BB’s unlimited private repos in particular), and Redmine offered an easy self-hosted project management solution including repository, wiki, issue reporting, etc. as well. Gitourious was available at the time but was (and is) feature incomplete compared to Redmine. I can’t remember if Trac supported either at this point.
So why consider changing? I’ve recently noticed what appears to be a mad rush to use Git in general and GitHub in particular–so much so that I’m wondering if Git is going to become the defacto industry standard soon. Changing to Git may not be as huge a deal as it might seem at first because Bitbucket, RhodeCode and Trac now let you use Git repositories in addition to Mercurial, and it seems Git’s support for Windows has improved. There are also a number of GUI Git clients available for all major platforms—though none of them seem as sweetly usable as EasyMercurial.
I may just try managing my next project with Git as a test-case. Worst case: convert the Git repo to Mercurial.