Git at Magnolia

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.

8 thoughts on “Git at Magnolia

  1. Perhaps you should articulate the reasons you don’t want a hosted solution?

    My default preference would be to go for a hosted solution as for a smallish organisation. I don’t see many advantages to self-hosting, only costs.

    However, there are legitimate concerns over a hosted solution such as security, legal jurisdiction (US government has legal right to seize servers or look at confidential code hosted with US-based companies) and regulatory issues.

    • Steven,

      Yeah – once I posted this … “article”, I was sure I’d miss some points. That’s one them.

      It’s not so much that I refuse to use a hosted solution, as much as some sort of general uneasiness towards the idea, and the lack of “control”. No real argument there.

      Another thing is integration with other (existing or not) systems. The use of keys in Git defeats part of this, but one would still need to create an account for whatever front end the tool has. And again, GitHub defeats this by its popularity (if my developers don’t have a GitHub account yet, they should, anyway) and its great API (I can probably script anything I want, much like I currently script creation of svn repositories, users etc).

      Lastly, an ideal hosted solution would have to provide all we need and more, so that I wouldn’t have to maintain several systems. And so far, that’s the show stopper. I haven’t seen a hosted solution that gives me fine-grained ACLs (private branches à-la Gitolite)

  2. Hi Greg. At our place we use Github for the (few) open source repositories, and mainly SSH and Gitweb for the internal ones.

    For public repos, there’s no reason not to have mirrors on Github, where people can fork and make pull-requests. That’s the distributed nature of Git coming into play. You just have to make sure the repos on Github are kept up to date with your “main” repositories (use a hook, or some cron-job to push). You can mirror your repos to Bitbucket too, if you want, nothing wrong with that.. As long as people know where the latest code is.

    For your internal repos, there are a few fresh kids on the block that you might find interesting:

    http://gitblit.com/ is a Git repo web frontend written in Java (perhaps that is particularly appealing for the Magnolia devs). It’s small, new, and therefore easy to work with. I wonder if it has limited support for hooks though, cause it uses JGit underneath, not native Git.

    http://gitlabhq.com/ is another interesting one: It’s an open source project, much like Gitorious, but they’re aiming to be very similar to Github. Looks interesting.

    Gitorious and the guys behind it, rock though. I think I would go for that now if Gitweb wasn’t enough for us.. Probably the best balance of maturity and features today.

    If you need any more advice on Git, or maybe git-svn, drop a line on https://groups.google.com/forum/#!forum/git-users

    Good luck with your migration!

    • Mirrors on GitHub are indeed on my charter anyhow. Do you have any idea if we’ll be able to merge pull requests from GitHub into our main repository ? Or should we merge into the GitHub repo and push from there to the main ?

      I’ll definitely have a look at GitBlit. Last I checked GitLabHQ… well, call me shallow, but it gave me the impression of it being run by a student in his bedroom, with no insurance at all it will hold to its promises in the mid or long term. Gitorious, yes. We have it running already… and might keep it up for public access, actually. Like in my comment above, I come back to private branches etc, which only seem to be available via something like Gitolite.

      Thanks !

      • A Github pull request is basically just a branch/fork with some GUI sugar coating. Let’s say if I fork Magnolia on Github, I create a branch “my-fix”, commit a couple of things, and then create a pull request for you. My repository would be here:

        https://github.com/tfnico/magnolia

        Now you can either use the Github GUI to merge the pull request, OR you can merge it the old-fashioned way:

        cd ~/projects/magnolia (your local git repo)
        git remote add tfnico-magnolia git://github.com/tfnico/magnolia.git
        git fetch tfnico-magnolia
        git merge tfnico-magnolia/my-fix
        git push origin (where origin is your main repository)

        Accepting a Github pull request basically does the above.

  3. Pingback: Git at Magnolia – now a reality ! | Greg’s ramblings

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>