Gitolite
42 points by matklad
42 points by matklad
In 2013 I set up a git server based on gitolite and gitweb at Cambridge University. I chose them because they looked like they would require much less admin time than the fancier alternatives (things like early GitLab or Gitorious). This turned out to be mostly true.
Gitolite is fairly eccentric, based on commands invoked via ssh and a fancy configuration file for access control. I suppose command lines are more popular now than they were then, but the lack of a web admin console makes it a bit offputting. I tried to make it easier to get started but it was only for the technically confident.
I needed it to require very little admin time because there was zero staff time available for running a git service. I wanted to demonstrate that there was enough demand to justify allocating time and budget, therefore to bypass the inevitable naysayers I stole some of my own time to spin up a stop-gap service.
I needed a git server for my own work, because I was using open source software distributed with git and keeping local changes in svn would have been intolerable, and storing the git repos in my home directory where no one else could find them was negligence. And I was aware (from things like Software Carpentry) that there was a lot of scientific programming going on but not enough software engineering support, and my department was mostly ignoring the gap. And I believed that we in central IT shouldn’t provide services just for our own use (pure overhead) but should design them to be useful to the wider university (and support teaching and research, which is the whole point).
Gitolite supported this bureaucratic hack by allowing me to delegate almost all of the user admin and support to a local expert in each research group or department who requested a shared account for their group. And because gitolite is fairly arcane, the kinds of people who signed up were exactly the kinds of expert early adopters I was aiming for. I was pleased that a fairly large number of people were actively using the service and I almost never heard from them.
(I was particularly pleased by one group whose project spanned multiple universities, because I had aimed to support open collaboration so I deliberately did not restrict access to just people at Cambridge.)
The main thing I got wrong was underestimating how long the stop-gap would last (silly me). It ended up being about 8 years, after which (as I hoped) it was replaced by a properly staffed GitLab setup. The biggest time sink was re-engineering it to improve its resilience: the near-real-time replication of the git repositories to another site was probably more complicated than necessary, heh.
Carrying on the story as the person who took on the service. We knew that we wanted to move to a software forge which also offered CI features and package repositories, etc, etc. Luckily, at that time, there was some appetite within the University to actually fund a central software forge as part of the general rise in recognition of software as a research output.
It was also around the time that GitHub was acquired by Microsoft and so it was the first time that GitHub was supposed to be on the way out. (It is amusing to see history repeating itself here.)
GitLab offered a license on very generous terms and we were looking to have a demonstration internally of the use of kubernetes and infrastructure as code for a Cloud-hosted service.
I'm no-longer at the University but GitLab is still running at https://gitlab.developers.cam.ac.uk/.
You were also iirc my git service’s second user (after me) :-)
At one point GitHub came to do a sales presentation which was from my point of view very poorly framed: they were not at all prepared to talk to people who had been doing open source since before it was called open source, and instead they assumed we would think of it as a scary new idea; their enterprise offering was designed to be a walled garden that (as far as I could tell) couldn’t publish software on the internet at all. Mirroring to github.com required enormous amounts of manualarity with no sensible way to delegate authority at the scale of a large research university.
Yes, that matches my recollection too. They lost the contract the moment they mentioned that a University wouldn't be able to share any of the output it generates!
I've used gitolite for its fine-grained ACLs, allowing some keys to clone-but-not-push, or push-but-not-force-push. Handy and lightweight!
Nowadays I'd try https://github.com/djmdjm/gitlimit
If it's just for personal projects, why not just use fossil? It has a built-in web server and quite happily serves quite simply with a very small binary. It even lets you talk to git things from upstream if you need to.
Gitolite is for hosting many repositories with many users with complicated access control requirements.
We used this at NRAO for some time, similarly to @fanf, as a stop-gap. My group lead set it up for us, and some other folks at the observatory who were interested in using git. The supported solution at the time was Subversion. Although I think we also maintained that.
I found it nice personally. It didn't do much but what it did do was perfectly sufficient.
We now have an observatory-wide gitlab install, and are maybe moving to github or gitlab (I don't think a final decision has been made and I'm far from where it would happen). We spend a lot of time fussing with the CI/CD system. I have no idea how one would support that from gitolite, or a pull/merge request workflow. Perhaps the utility of those ideas is overstated.