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

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.)

@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.
@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 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.