Re-thinking my git hosting with sourcehut and forgejo
Introduction
TLDR; I’ve moved my project to sourcehut, see my projects there, while maintaining a private and local forgejo instance.
Last year, I realized that my projects were in too many repos. I’ve been using github like many others for a long time, but I also had an account on gitlab, codeberg and sourcehut. I also have a few account on selfhosted repos from specific projects, but I’m not going to talk about these cases in this post.
After years of pushing codes everywhere… I had projects everywhere: github, gitlab, codeberg and sourcehut… So it was time to do something about it!
Context
Early last year, after testing sourcehut for a while, I was convinced it was the best forge for me. The “for me” is important, because I don’t think sourcehut is for everyone… And while it isn’t perfect (in particular its UI and how to navigate between each sourcehut features), I find it the best for my needs.
But at that point my repositories were a mess: projects were either on 1, all or a subset of the mentioned forges… Clear primary forge was not indicated and no way to have a good vision of all my projects… Let’s just say that this was not ideal and even myself wasn’t sure what were where…
And then sourcehut (and codeberg to a lesser extent) suffered massive DDoS attacked that put them down, specially Sourcehut that was out for multiple days. That event made me realized 3 things:
- I wanted a go to forge as my main “public” forge
- I needed a selfhosted forge to still push code during downtime of my main public forge
- I had to do some cleaning and clearly archive / close unused / unmaintained repos
A good question would be: “then why not just using one selfhosted platform only?”. But hosting my own forge publicly comes with big drawbacks:
- I’ve found that bot crawlers are taking a lot of resources to crawl all public repositories.
- Git access via ssh (to push) would need opening port 22 to the internet and do a lot configuration in my network.
- A “known” public forge is usually easier to contribute.
So I rolled up my sleeves and decided to go through the migration to what I hope is their final destinations…
The plan
Objectives and Constraints
The goals were simple:
- Have one main public forges for all open source projects: For that, I choose sourcehut1.
- Have a selfhosted forges in case I want to push code and sourcehut is down. Also to host projects that I don’t want on sourcehut, even as a private project.
- Clear indications for users / contributors on where to find the up to date version of a code.
Exception
I made 2 small exceptions for the 2 gemini RFC proposals. Collaboration are already taken place there and I’m sure some people had to create account to participate there and may not want to move. Also, as it is an RFC, having a small UI to edit the text and create a merge request may be easy than the git email workflow. That is why the Gemini Tinylog RFC and the Gemini Mention RFC primary repositories are still on codeberg.
All my other repositories follow the new plan.
New state
Local Forgejo Instance
As said, I decided to use Forgejo for my local private instance. I won’t cover the installation details, their documentation covers it well already.
This instance is only used by me for:
- Private repository that I don’t want on sourcehut (even in private) or any other public forges
- Very old and unused code that I want to keep
- Hosting the code of all projects I host elsewhere. I don’t use mirroring here, I actually have to push to multiple remotes (see this post where I explained how I do it via
git remote --set-url) - Sometimes used to push things before I push them publicly to sourcehut (or other)
- Serve also as a backup of all my code: the instance itself is a backup of project on 3rd party forges (or the other way around), but also, the container hosting forgejo is part of my backup process with proxmox and borgbackup, so all covered :).
As you understood, every single project managed by git is hosted on this private instance. It isn’t used for anything else (no CI/CD, no public pages, no collaboration).
Sourcehut
The new public home for all my projects. Took a bit of time to get used to its UI and workflow, but I really enjoy using it. I won’t detail right now how sourcehut works differently than other “traditional” forge (=aka github workflow), but I’ll talk about why sourcehut in a later post.
One important thing to have in mind: on sourcehut, you can create projects to group multiple repositories (themselves attached to mailing lists and todolists) together. It means that you can have one project with mutltiple repositories but still a common todolist for example. It also allows to have a git repository in multiple projects, which can be useful too (see below as I’m using it).
It takes some time to grasp the full concepts of sourcehut, but the flexibility is way higher than with other forges. I’m using sourcehut projects for grouping codebases together or for “larger” projects on which I’d be happy to see collaboration. Smaller code are not in projects and just standalone repos (with mailing list and todolist still possible).
Sourcehut allows projects and codebases to be visible, unlisted or private. A project can have repos with different visibility.
For example, I created a writting project that contains 4 repositories: one for this blog, one for my gemini capsule, one for the deployment scripts (unlisted) and one for my custom hugo theme. The hugo theme is both in this project and in a dedicated one in case people would like to contribute. Other example, I have a gemini55 project containing all my gemini related repositories (gtl, houston, ggm, discogem and a link to the 2 gemini RFCs). Some repositories are not tight to projects.
What about other forges
Except the 2 Gemini RFC exceptions mentioned above, I’ve cleaned a lot my other forges presence by archiving all projects (and that took some time to do on all projects :D). Both my github and codeberg profiles indicate:
Profile used to contribute to Github projects. My own projects are hosted on sourcehut: https://sr.ht/~bacardi55 https://git.sr.ht/~bacardi55
I haven’t deleted my account on those forges though, as they might still be useful to collaborate on project hosted there.
Conclusion
The move is now over, I have been using solely sourcehut for quite some time now. This blog is now built via sourcehut builds and while sourcehut UI definitely needs improvements, it has been a great decision and I’ve enjoyed a lot using sourcehut since my move. Hopefully, this is a state that shouldn’t move for a while.
-
: Some people might argue that sourcehut is not the best choice for this because it doesn’t provide the “classic” fork / pull request workflow, but I do believe anyone could learn fairly quickly the email workflow linked to sourcehut. Plus my project don’t have contributors in reality :P. ↩︎