Tuesday, August 21, 2012

On git and gerrit

We've now been using git and gerrit for mediawiki for quite some time. I must say the software has grown on me quite a bit. When we first switched, I hated both of them. Now that I've had some time to adjust, I've discovered that I really like git, and I don't hate gerrit quite as much as I used to.

First of all git. Git is quite cool from a technology standpoint. In my usecase I like how it has the ability to work on multiple different features at once, since you can have multiple local branches. On SVN when I wanted to do that, I had to use workflows like svn diff > somefile.patch; svn revert. With git I can switch to different branches easily, and its all still contained in the version control system.

The ability with git to easily work offline is also very nice. I currently don't have an internet connection at home (and no neighbour's wifi to steal either, I don't know what this world is coming to ;). Git makes it much easier to develop features without having to go to somewhere like a library. [Note: The no internet thing is by choice, and is a way to force myself to waste less time on the internet. I can work on things, save (commit) it to a branch, work on more things, commit that, all well being in isolation from the rest of the inter-connected world.

The only thing I do slightly miss from svn, is incremental revision number. In SVN, each version of the code had an id number, and they went in order. With git it is a totally random sha1 hash (aka 6176d71256aa94a25c471c8696f28820f0b4e8e7). This is less annoying than it might seem at first glance, however it means when I do git blame I get these sha1 things rather than monotonically increasing revision numbers. This makes it harder to tell what version something was introduced in because I can't just look up the revision in the [[mw:Branch points]] page. (To be fair, git also provides a date, which helps somewhat).

Now on to gerrit. Gerrit has certainly grown on me. I think this is a combination of getting used to it, and the new skin we started to use. However, I still think the interface is horrid, and I miss [[mw:Special:CodeReview]].

The interface to gerrit is pretty confusing, especially at first. Almost everyone doesn't understand how to save an inline comment the first time around (Hint: you also have to save a non-inline comment for it to go through). I don't like the fact I can't use wildcards when searching for projects (aka cannot do project:mediawiki/* to get mediawiki/core as well as everything in mediawiki/extensions/... ), since I mostly don't care what happens in ops (Although I am very happy to see how ops is becoming more and more open - Good job ops folks!). You also cannot do a search for everything that matches some certain path (AFAIK, however you can set up email alerts based on paths), which was easy to do in Special:CodeReview. Free-form tagging of revisions would also be nice (Another feature missed from Special:CodeReview). Last of all, the gerrit user interface begins to get really clunky when a patchset has been amended multiple times (Also I wish git review should ask for a patch-set message if its not the first version, it is a real kludge to modify the commit message with Patchset 6: rebase type messages). With that said, I do understand from the gerrit alternatives discussion that gerrit is the only system that really even remotely meets our needs, so I am by no means advocating switching.

I suppose one of things I most like less about gerrit (But understand the reasons for, and am not advocating changing), is the gated trunk model. For the non-technical audience (although to be honest, I'd be surprised if anyone is actually reading this, and if they are, and are non-technical, that they got this far), the gated trunk model is roughly a spiffier version of FlaggedRevisions/PendingChanges, but for computer programs instead of wikis. I've found it has some of the draw backs that FlaggedRevs detractors were all talking about — namely less instant gratification. In the SVN days, if you had commit access, you coded your feature or bug fix, hit commit, and that was the end of that. Sure someone would eventually come along and review it (In a similar way as how edit patrol works on wikis), and reviewers were not afraid to revert something if there was something wrong with it. However you still had to do something wrong in order for it to be reverted. With gerrit, it requires someone to approve your commit, as opposed to merely someone not finding an issue with it. Thus if nobody cares, your commit could sit in limbo for weeks or even months before anyone approves it.

So all in all our great glorious git future is growing on me more and more. There are still things I miss from the old system, but with time, perhaps that will no longer be the case.


  1. "For the non-technical audience (although to be honest, I'd be surprised if anyone is actually reading this, and if they are, and are non-technical, that they got this far)"

    Do I count? :-)

    More seriously, thanks for writing this. I think the pre-merge review is better for the frequent deployment style Wikimedia is aiming for, but there certainly is the limbo downside, which I hope to mitigate by helping encourage more reviewers.


    1. >Do I count? :-)

      Nah, you're in the technical category :P

  2. 1) I also welcomed the paragraph on the gated trunk model. Just FYI :)

    2) All 3 links on this post point to mw.org, but each uses a different formatting. It's nitpicking, but wouldn't you rather use the same markup for all three?

    3) "I do understand from the git alternatives discussion that git is the only system..." → s/git/gerrit/g

    1. Glad you liked it. For the first two links to mw.org I was trying to emphasize the page as a tool with in itself, where the last link I was just trying to link to more information.

      Fixed git/gerrit mix up, good catch (all these gi sounds start to roll around in your head and get confusing)