Switching to cgit
Author: Jake Bauer | Published: 2020-07-05
I’ve been using Gitea for almost six months as my self-hosted git server. In that time it has served its purpose and done well, but it’s fallen into the same traps as other platforms like GitHub and GitLab. That is to say, Gitea feels very slow to use and I don’t have any need for the plethora of features it offers.
What I Didn’t Like About Gitea
Regarding this first point. A typical page on Gitea took at least a second to load, if not longer, and usually weighed between 2 and 3 megabytes. I didn’t do any rigorous testing of large diffs or anything like that, I just loaded up the front page and my profile page. Compared to cgit, which takes milliseconds to load and has page sizes comparable to my website (10-20 kilobytes), Gitea feels agonizingly slow to use just like GitHub and GitLab.
Regarding the features, Gitea comes with things like built-in repo wikis, CI/CD, social features similar to GitHub, a system for multiple user accounts, and more. I used none of these features; I basically just used Gitea to host my repositories and I dislike the pull request development model anyways.
Setting up cgit
When I did my comparison of self-hosted git services, cgit caught my attention as being light but not as light as something like Gitweb such that it still has some useful views and features. cgit isn’t a software forge, only allowing viewing repositories and downloading files, but it has all I need out of a self-hosted git solution.
Setting up cgit was fairly straightforward. I just followed the Arch wiki
tutorial on setting up cgit to set
up nginx with fastcgi, python-pygments for syntax highlighting source code, and
I read the cgitrc(5) manpage to flesh out the rest of my
Switching over was really easy too. I just copied the repositories that already
existed on the server to a new location (I chose
/srv/git) and then switched my
reverse proxy to point to the new git server’s port instead of Gitea’s port.
Following that, I just decommissioned Gitea by stopping the server and deleting
any trace of it off of my system.
One thing that I wanted to try doing to cgit was adding a dark theme that would
be activated by a CSS
@media query. Unfortunately, I found the cgit CSS file
to be a huge mess of mixing colour names and hex codes with no use of CSS
variables so it would be an absolute pain to change things. No disrespect to the
developer though, I have a feeling that it’s because the file has been growing
over time as features have been added and it doesn’t get a lot of development
What I did to improve it was to go through the whole file, collect all the colours that were being used, and consolidate and turn the colours into CSS variables that could be re-used throughout the file. If you were following some of my toots on Mastodon, I posted about how some 7 slightly different shades of grey were being used which I pared down to 4. I also turned the font-size and logo-width into CSS variables so they would be easier to change from the top of the file. I have yet to design a good dark theme (this will take some time to ensure it’s completely accessible), but I feel like the CSS will be a lot easier to work with now.
I did also make some other improvements throughout the CSS. For example, I set
my base font-size to
100% instead of the ridiculously tiny
10pt, I added
underlining to all links in tables (because previously you had to hover over
them with your mouse to distinguish a link from just plain text), and I improved
some colours to ensure that there were no contrast issues. I also used the
borland theme in python-pygments because it had no contrast issues against the
white background unlike
I’m not quite sure if I’ll be able to get a dark theme working, but I have made all of my customizations and settings available in its own repository for others to look at. Here is the repository on my git server.
This is my sixty-first post for the #100DaysToOffload challenge. You can learn more about this challenge over at https://100daystooffload.com.