So, where do the cool kids host their code these days? I went to GitLab and saw “Finally, AI for the entire software lifecycle” – ok, I guess this means no GitLab for me. Codeberg then? Or something else?

Note: no, I’m not self-hosting. Yes, I know how to do it, I’ve been doing it for a decade. But I still won’t.

#Github #GithubCopilot #GitLab

@WPalant Gitea/Forgejo have cloud offerings IIRC, they are pretty solid too for regular repo stuff.

@buherator Concerning Gitea I found https://about.gitea.com/resources/tutorials/gitea-mcp-server. This is not a core feature at the moment but I don’t really want to migrate to another service and have them start shoving this down everybody’s throat a few months later.

I cannot see any cloud offering for Forgejo.

@WPalant Codeberg is excellent IMHO. Sponsor if you can.

@WPalant MCPs are the least intrusive way for LLM integration IMO, so I wouldn't see too much into that but you do you!

How about managed services? Like deploying a Gitea AMI on EC2:

https://aws.amazon.com/marketplace/pp/prodview-lhdotldtcz2ke

@WPalant codeberg seems cool but it doesn't really allow private repos

@freddy Luckily, I don’t have any private repos (not on Github at least). I have no problem self-hosting a few private repos if I need them.

@WPalant Codeberg or maybe Sourcehut. As at least the former is operated by a non-profit, check if you can spare a penny.

Ok, the people have spoken. I’ll be looking into migrating my repos to Codeberg. I plan to remove all repositories on Github and to create archived placeholders in their place linking to the new location (I don’t want to leave any repository history there).

All is done I think. This has been a ton of work but I’m now a proud owner of a Github account filled only with placeholder repositories. My 25 repositories (the ones that were worth migrating) live on Codeberg now.

On the bright side: the code adding blog comments to repository got quite a bit simpler, Github API is quite a mess when adding multiple files in a commit. The downside: Codeberg CI will only do Linux. So if I ever have to make a release for one of my Rust projects I’ll have to figure out how to cross-compile for Windows and MacOS.

Other than that migrating actions was fairly straightforward. You substitute ubuntu-latest for codeberg-tiny (or whichever size fits), update action locations and it works pretty much the same as on Github. Web hooks and static websites also work pretty much the same. Unexpectedly, the hard part here was migrating the releases – copying information manually for 35 releases in a repository is no fun. Well, that and updating links, turns out I have tons of them.

Deleting Github repositories and creating placeholder repositories instead destroyed some state unfortunately, issue reports in particular. Too bad but I really didn’t want to leave any data on Github.

@WPalant I took a different approach — I kept each repo in place, but replaced the actual git contents with a single branch, single commit, single file (a README saying "moved to <link>").

For anyone else reading this, I'm happy to share the script I used for updating repos this way. (Hmm, Codeberg doesn't have the equivalent of gists.)

@varx It’s an option but repository contents don’t go away. It is up to Github to actually remove the commits which aren’t reachable via the UI.

@WPalant I tried compiling a Rust project for Mac last year and was annoyed to discover that Apple wants you to go through some kind of developer signup program and sign a document or something in order to... compile. Throws a wrench in all the automated cross-compilation tooling.

So I'm just not compiling for Mac for now.

@varx macOS is really taking pride in being the most developer-unfriendly platform there is… Yes, just not compiling for macOS is an option worth considering.

@WPalant Don't you have the same problem with deleting a repo?

@varx Not really, I can reasonably expect Github to dispose of my repo then. Unreachable commits are an entirely different beast. From what I remember these stay around for at least 30 days, and Github has to actively prune them. I’m not sure they really do it for all repositories regularly, particularly the inactive ones…

@WPalant It might not be that simple. I suspect that if a repo is part of a fork network, they actually have pooled storage of the commits.

Hmm. One way of testing this would be to:

- Make a repo A
- Fork it to B
- Add a new commit to A
- Confirm that the commit is reachable from B (a weird thing that GH supports)
- Delete A
- Check whether the commit is still reachable from B (and if so, for how long)

@varx True. If there are forks then you’ve lost no matter what.