You might have heard or read about it, Magnolia is finally moving to Git.
The main reasons for this move are the pains of merging and branching (i.e we just don’t branch as much as we should because Subversion makes it painful) and pull/merge requests as a way to make contributions simpler for users as well as for us to integrate.
I’ve been investigating tools for a while and I’ve come to a few conclusions… and more questions. Some of the requirements for having our codebase moved to Git make this choice a little more complicated than I’d like.
So before everyone cries out and asks why we’re not simply on GitHub already, here’s a couple of details about our infrastructure that will shed some light on that question:
- Private repositories (the codebase of the Enterprise Edition is not public, and we also have a bunch of internal or customer projects which we can’t, eh… publish.)
- Fine-grained permissions, too. We don’t necessarily want (or are allowed to) expose all branches to the greater public for example. (customer-specific or experimental features)
- Ideally, I’d like to avoid having to maintain different systems.
… but there are great things we “need”, which GitHub and some others offer:
- Merge requests, as mentioned above.
- Commits and branches graphs. That’s a given with something like
git log --pretty=oneline --abbrev-commit --graph --decorate, but even if only for admins and maintainers, a visual representation of branches and merges without having to fetch the repo can be very useful.
I initially dismissed GitHub (which offers private repositories or offers a self-hosted appliance) for pricing reasons. We currently don’t have many committers for the main project, but when taking into account Forge users (and I’m hoping many more will join!) as well as Enterprise customers (who have read-only access to our EE codebase), the number of users increases exponentially.
However, prices for private repos at GitHub seems to have been revised recently though. And Bitbucket now supports Git, which makes it another attractive option.
Nevertheless, in my quest for a solution that would involve maintaining the least amount of disparate systems possible, as well as the flexibility needed for some of the points above, I am investigating other options.
A couple of weeks ago, I installed Gitorious (Gitorious is not just a hosting service, their software is also self-hostable). It’s a great piece of software, and covers most of our needs, but it is lacking in a few departments for us (most notably the private repositories – but there is finally progress on that front); it is quite monolithic, and I don’t feel comfortable dabbling in its codebase (as opposed to patching a more focused Gitolite or Gitweb, for example)
My current plan is to try out Gitolite, front it with Gitweb or Fisheye, as well as have it push/replicate our public repositories to GitHub. I’m hoping pull requests on GitHub could still work, even if our master repositories are not hosted on GitHub.
If that fails, I’ll probably look at Bitbucket closer. Perhaps I’m old school, but I don’t feel comfortable hosting our private repositories elsewhere, though.
And this is where you come into play. Do you have any suggestion ? Any possibly better idea ?
… I should have asked a long time ago.