Why GitLab is Not Ready for Big Repos

It’s rare that I have to complain about something enough to make a blog post about it, and my experience with GitLab has definitely met the criteria.

GitLab is a git repository hosting system with many similarities to GitHub, the largest code repository hosting service in the world.  The biggest, and possibly the best difference between it and GitHub is that GitLab is (mostly) open-source:  You can download the GitLab Community Edition software, chuck it on your server, and boom, you get world-class git repository management and the ability to handle Merge Requests (GitLab’s version of the ubiquitous Pull Request).  In addition, more fine-grained permission controls are available, MRs are rebased before being merged, issues are easier to handle, MR templates can be mandated, and a slew of other handy features.  For Space Station 13, a game made by SomethingAwful and 4chan, GitLab was also attractive due to a more compatible ruleset regarding potentially offensive content, hopefully allowing us to avoid the same fate as Webm4Retards (now Webm4Gits).

So, for small repositories with little in the way of binary files (such as images), GitLab is actually a very nice, flexible git repository hosting solution.  When you start talking about repositories with thousands of images and a near-decade of commits, such as is the case with an old videogame project, you run into problems.

Over two weeks ago, developers trying to fork our repository on gitlab.com started receiving errors, usually with a message regarding gitlab-shell, which is the back-end worker that interfaces with git and manages the repositories.  We reported this issue to GitLab, and it was found that the git process that actually does the forking was taking so long to perform its duty that it timed out and was killed, leaving behind a partial, broken repository that broke the ability to retry the forking process.  Later on, on forks that already existed when the issue cropped up, it became impossible to make merge requests for similar reasons.  As of the time of writing, merge requests on our repository are still broken, and the fix for the forking problem is still not deployed (scheduled for the 22nd with GitLab 8.0).  In addition, the fix for the forking problem overlooked the merge requests being similarly broken, and does not address any other activities that would time out.

Seeing as we have an active game in development, there are several active security exploits for said game making the rounds, and we’ve been without a working repository for upwards of two weeks, we made the decision to move back to GitHub.  While GitLab certainly had many things we would have liked to keep, a working development repository is more important than the attached bells and whistles.

We appreciate the GitLab developers prompt assistance in working with us to resolve these matters, but we cannot wait any longer for our repository to regain functionality.

As for my personal, smaller projects, they will remain on GitLab.