This post is inspired by a Fediverse post I read a while back about someone deleting a patch that they wrote and wanted to publish but couldn't because of a real name policy. I understand the desire for real name policies. I don't agree with the reasoning. Privacy is a big concern, especially in this ever-growing dystopian hellscape that we (developers) have helped Big Tech create. I unfortunately lost the link, as Blahaj Zone doesn't seem to have a way for me to search only things that I starred. When I come across it again, I will edit this post.

Git is decentralised and semi-private by design. Anyone can create PATCH files and contribute to a repository without an account. Anyone can create a git repository and share it with the world. Real names should not matter, as long as your GPG key is intact and your commits are signed. Ideally, your key will also be registered with various keyservers and published on your own website in order to establish a chain of trust. Your key is your identity, as well as your reputation.

In addition to real name policies, git users are seemingly migrating towards a centralised approach. Long gone are the days of public mailing lists that anyone could (un)subscribe to at any time with an email address and nothing else. Everything today is seemingly on GitHub (and derivatives) where one must make an account and accept a privacy policy on top of a license agreement on a centralised server. Repositories are also subject to content moderation policies set by the server operator(s). There's also the issue of DMCA takedowns that shouldn't even impact open-source code to begin with. This does not look like decentralisation, openness, or freedom to me.

Sure, there are alternative providers, and even self-hosted GitHub-like solutions such as Gitea and Forgejo (which Codeberg uses), or even SourceHut for those who want a more classical design. Those solutions still have the same fundamental issue - to contribute to a repository, one must make an account. Forgejo is in the process of implementing federation, which is a huge step in the right direction. I'm not sure how transferring servers would work. It is worth keeping an eye on.

With that said, as part of my continued commitment to decentralisation, I'm returning to the days of yore and using plain bare git repositories on a server and a soft fork of rgit to serve them to the public. You can see that in action here. It isn't perfect, but it works for me. I've already submitted a patch to upstream to fix a Docker container issue and it was a rather pleasant process.

There are a few things I'm missing as a whole, like HTTPS cloning, an issue tracker, the ability to download a tarball of the active branch, and custom themes. The frontend does have support for showing release tags, but the download links do not generate. Those are things I will be attempting to fix and submit to upstream as I become more comfortable with the codebase.

In my research, I found this helpful post by Simon Willison, which may lead me in the right direction to produce the tarballs. This gitweb-theme by kogakure has helped me to produce a CSS-only theme for rgit. There are several things that need to be adjusted at the template level before I am ready to publish that.

In the end, I'm hoping to have a setup that is a simple and modern take on an older system that can be deployed as a single container.