TL;DR

Gitolite is a neat project.

So there’s a group of an unspecified number of developers who would like to start tracking code in a place that is also “central” and properly backed up.

A very wide need, which demonstrates that whatever people might say about Perl and its health, the very foundational notion that there is more than one way to do it has taken over the whole dev world and is well ingrained pretty much everywhere. Which is also the case… in this case.

There are Software as a Service alternatives, of course, like GitHub, GitLab, BitBucket and the like. They do tick a lot of the checks, have a widely generous free tier and allow to have private stuff. As any free service, though, they owe you nothing and I think there were plenty of past experiences where this turned into a cold shower.

I’m not complaining about this, I understand that these are business entities whose mission is not necessarily to provide free services around and that might aim in different directions in the future. I’m only saying that this decision must take this into account.

The paid alternative would be marginally better, of course, with support and people to take care of the lifecycle. There is still the threat that companies might go in a different direction and leave customers with a burning matchstick in their hand.

A lot of differences comes from the features these platform give. If you need them, then they definitely have a weight.

On the “on premises” side there is a wide range of alternatives.

There are those that provide some web interface, like the full suite from GitLab (which provides so much more than just Git repositories management), down to the phylosophically aligned alternatives like Gitea and GitPrep (to name a few), or other approaches like Girocco.

Then come solutions like Gitosis (which I understand is somehow unmaintened so far) and Gitolite, which is a very neat project.

As you might have guessed… I’m trying out Gitolite. I hit a few bumps so far when setting it up, but nothing blocking. In both cases, it has to do with the recent wave of changing the default branch name to something neutral like main.

The first problem was that the fresh Git install I had in the prototype “server” (well, it is actually a COUGHKubernetesCOUGHPodCOUGH) insisted on setting up a name for the default branch. So I did set it to main, and then run the setup for Gitolite. Which meant that the administration repository gitolite-admin got a default branch named main. Which meant it didn’t work.

The second issue has to do with having users set their own default branch name and this being at odds with what the server thinks it should be. This has been discussed too, but it seems that there’s no solution out of the box.

All in all, these are … opportunities to look into! So we’ll experiment with Gitolite, and probably settle with it for some time, until we feel the need to step things up.

Stay safe!