Playing with git

I suddenly felt the need to self-host my git repositories after spotting cgit on Valhalla’s blog. The ghost of covetousness appeared and I wanted one. Unfortunately, as I’m on a shared-host, it is not possible to have much fun with the likes of cgit.

I can however, install the PHP gitlist, so I tested it but could not find any themes anywhere on the entire Internet. I found P3X Gitlist which is a fork with heavy modifications, and tried that one as well; better. It works fabulously but is a bit too heavy for my humble needs. P3X Gitlist allows editing and I don’t want that; I am looking for a read-only git viewer. Configuration is possible and I did manage to turn off the editor. Then there are the other tweaks to make to themes, et cetera… it’s chock-full of Javascript and uff! It’s heavy. P3X Gitlist is very nice, it works well but I don’t want a full Github-type thing with all those bells and whistles like RSS and graphs. The uncompressed folder is a whopping 25MB.

I could spend some quiet time tweaking it to get it behaving and looking like I want. Or, I could make my own. How hard can this be? All the data exists already in the git repos, so it is just a matter of pulling it in: the repository names and descriptions plus the commits with all the authors and committers. What about all those diffs? I want that too. The challenge I think lies only in displaying the data.

PHP would be nice but I’m a bit rusty on PHP. And I like the simplicity of cgit which runs in a CGI albeit written in C. I don’t know C, but I do know Python and I sort-of remember how CGI works (it’s been a minute there, too). So let’s play.

Learning more about git

Problem Number One: whilst my shared-host allows for git hosting, it does not allow Smart HTTP. That means that I can host gits to my heart’s content, push and pull via SSH and do everything else, but it is impossible to clone via Smart HTTP. And I want to enable cloning.

After a bit of reading, I learnt about --bare repositories. I’m not a developer, so why would I know about bare repositories? Well, now I know! It turns out that bare repositories can be cloned very easily via Dumb HTTP, as the files are served in about the same way as, say, a HTTP file is served. How cool is that? The clone receives the working tree as well even though what they clone is just a bare repository… that part blew my mind and I still don’t get how, but maybe one day I will. It’s like magic!

Problem Number Two: bare repositories require git update-server-info to be run each and every time an update is pushed to the repository. Via hooks, or manually, but hooks are probably best. Yes, definitely hooks.

I have heard about hooks but have no idea what they can be used for, so I’ve always just ignored them. Some more reading.

When serving a bare repository over “dumb” HTTP (no git-upload-pack/smart HTTP), Git clients reconstruct the repo from static files the server exposes. Running git update-server-info in the bare repo after any changes will instruct the server to publish info/refs (listing branch/tag names and tip SHAs), objects/info/packs (listing available pack files) and HEAD. With those files present and readable via HTTP, clients fetch info/refs to discover refs, then download the listed pack files or loose objects and reconstruct the object database locally, after which they check out a working tree.

That helps somewhat in my understanding of bare repositories. With regards to hooks, as I understand it now, they are simple executables which can be run at certain points in a workflow. They need to have specific names (as per the samples provided in /hooks). Got it, finally!

Once I reached a better understanding of bare git repositories and hooks, it was time to apply my new-found knowledge. I also learnt that git is not like Ikea flat-pack furniture where you can get away with skipping the instructions; read the docs.