One year with Codeberg
98 points by untrusem
98 points by untrusem
Very cool to see some real project metrics related to a codeberg move! I personally hope that codeberg becomes the new GitHub, as there's a million reasons to move away from GH. I personally went to my own forgejo server, but I am now using codeberg as my backup target for all repos.
I personally hope that codeberg becomes the new GitHub
I know you mean this in the best way possible but I'd rather not have everything move to Codeberg, but have many separate forges communicating via ForgeFed.
We don't need a new Open Source Nexus.
I don’t even want to see Git monoculture. There’s a lot of great VCSs out there.
I am very happy with the git monoculture. I don't want to have to keep up with the latest VCS.
There are a lot of oldies, but goodies: Darcs, Pijul, Fossil, Mercurial—no need for the latest ‘vibecoded‘, Claude-told-me-this-is-revolutionary VCS. They have technical merits to choose, but monoculture around tooling & hosting ends up being a dominant deciding factor—which is further pushed by thinking we all need to be on the same centralized code forge (ironic since the D in DVCS, which all of these are, is for distributed).
I think the free market handled VCS quite well tbh. We have git for almost everything, except for places where it isn't up to par like game studios, and those guys use perforce for now.
There is so much tooling to work around Git’s limitations when some fundamentals could have been changed. If you have seen like Gerrit’s changesets as stringly-typed trailers slapped in the commits, this behaves more like a hack rather than solving those fundamental issues. For instance, the Patch Theory-based VCSs can completely eliminate time & patch order from merge conflicts which allow a workflow that actually works better with the distributed part of DVCS—something that almost always means you need a canonical repo to work with Git in teams even if supposed to be distributed since syncing up can lead to a lot of issues if you applied patches in a different order. Most folks agree this model has advantages—often said is wholly superior—but we are stuck with Git due to momentum, not actually the “free market”, *puke*, allowing the best solution to win out.
I am eagerly awaiting forgefed to become a real thing. I think federation makes perfect sense for Git. I've played with Tangled, but that obviously has some major drawbacks in its current form. I long for a day when any git repo anywhere can PR to any other git repo anywhere.
What are thre issues with Tangled? It looks very well-designed.
I'm also curious on the parent poster's take, but personally I'm suspicious of a few things:
I think everything is less decentralized in practice than it's proponents want it to be. I care less about how centralized something is and more about whether I can own my data or not. In the ATProto case and in Tangled's use of it I definitely can.
Instead of having forges communicate with each other, it would be easier if issues/PR's etc... was just hosted within the git structure itself. Git already supports having multiple upstream remotes, thus it would be easy to do.
I think Fossil does this but I'm unsure if it supports multiple upstreams/mirrors etc..
I think Fossil does this but I'm unsure if it supports multiple upstreams/mirrors etc..
Seems the answer is yes https://www.fossil-scm.org/home/help/pull#:~:text=from%20a%20remote%20repository%20into%20the%20local%20repository and if one keeps reading it covers all the use-cases this thread is mentioning:
Sharable changes include public check-ins, edits to wiki pages, tickets, tech-notes, and forum posts. Add the --private option to pull private branches. Use the "configuration pull" command to pull website configuration details.
I don't have an example setup to try it in order to know if the upstream changes are qualified (e.g. origin/main versus my-mirror/main, or origin/ticket-hash-here versus my-mirror/ticket-hash) but I'd guess the answer is "no"
From all the forges I've seen, codeberg just feels cleanest, but I still don't know if it's ready for my code yet. GitHub is still the defacto standard people expect, and when it's just my solo projects, all I really need is a place to push my code incase my ssd fails.
I do also like the look of Codeberg.
But what I like even more is it being built on Forgejo making my self-hosted git-forge feel just like Codeberg without any context switching necessary between the two.
GitHub is still the defacto standard people expec
This is my biggest issue with the Forgejo project. They try to copy as many MS-GitHub-isms in the fork from Gitea to I guess make the transition more ‘seamless’, but I see it as inheriting rat’s nests like the YAML of Actions instead of trying to fix the issues as a bigger selling point beyond that the UI isn’t sluggish.
I know it's mostly laziness but just correctly guessing github.com/PROJECT has come in really handy for the last 15 years.
It was kind of a nice side effect and while I totally support decentralization it saved me a ton of bookmarks and finding stuff.
I don't think Forgejo currently scales anywhere near well enough to allow this. The codeberg folks are doing what they can, and I hope this will change, but it'll take time!
I ended up moving everything I work on personally to Fossil, and setting up my own Fossil server for the things I want to expose to other people. It's been great, I definitely prefer it over git (though that bar isn't super high nowadays).
TIL about the AGit workflow:
a way of submitting changes to repositories [...] using the git push command alone, without having to create forks or feature branches [...]
This! It's really nice that this is possible and I wish it was better known, better-advertised, easier to use.
Note: it's weird that most forges are not able to open a PR without forking the repository in the forge itself, given that git format-patch ... is pretty easy to use to generate a clean set of patches. It sounds like it should be pretty easy to show people a form where they upload a patchset file, indicate the target reference in the target repo, write a description, and that's it.
I initially hoped that Gitlab would work on this, and use this to implement PRs from one Gitlab instance to another. I'm one of the poor sods who spent years subscribed to relevant issues on the Gitlab bugtracker (eg. the Creating merge requests from patches from 2018, or Implement cross-server (federated) merge requests from 2015. It became clear over the year that the people who make decisions for Gitlab do not care about this -- presumably, but I can only guess, because making federation easier is not going to help their business model of attracting rich companies to pay them for various services. There is also a constituency that was pushing for very complex solutions, for example "let's support ActivityPub and use this for federation", and I never understood if it was intentionally a delaying tactic.
It's really nice that this is possible and I wish it was better known, better-advertised, easier to use.
It is advertised on large repositories like the Gentoo one. As a way to reduce resource usages due to forks with large repositories Codeberg is looking to favor the agit worflow. For example they are requesting that Guix switches their UI so that the fork button is replaced with docs to the agit workflow documentation, https://lists.gnu.org/archive/html/guix-devel/2026-06/msg00007.html.
For Emacs users there is agitjo, which I've found pleasant to use.
I initially hoped that Gitlab would work on this,
Merely as an observation, they have a pretty long track record of helping contributors get started fixing their own issues. So, sure, if you're waiting for GitLab the company to prioritize your personal wish list to support a future where people use email for collaboration, yes, you're going to be holding your breath for a long time. On the other hand, if that feature is the one keeping you from using GitLab in your setup, then https://docs.gitlab.com/development/contributing/ is a fine place to start closing that gap
Merely as an observation, they have a pretty long track record of helping contributors get started fixing their own issues.
Can you point to some examples, specific community-contributed changes that you have in mind that reflect this?
My experience interacting with gitlab-the-software, besides this hope (disappointed again and again every year) that they would make steps towards allowing MRs across instances, was the following:
unzip implementation used by gitlab: https://gitlab.com/gitlab-org/gitlab-runner/-/work_items/27496
unzip implementation should work correctly by default.(At the same time I also noticed that it would be a major help to CI output readability if CI script authors could control which lines get included in the CI logs, and for which lines (typically echo ...) only the output is shown, for example by reusing the @foo syntax of Makefiles. Turns out that this had been a requested feature since 2019, which never went anywhere.)
One very irritating thing I've discovered since I began using Codeberg is that hardly anything at all truly supports git integration; it's almost exclusively GitHub / GitLab only.
cries in magit forge
So this will not be for all the people but in emacs we have forgejo-vc and fj.el, so 95% of the time I don't even have to open the browser.
and for cli, there is forgejo-cli.
I'm referring mostly to third-party integrations, like say you want to deploy your repo to a static host.
Funny that you mention this....so I'm in the middle of moving over a few static websites to Cloudflare's Pages functionality (i supposed similar in concept to Github Pages, etc.)....so as i review the options for git integration, and what do you know, they only support git as long as its either github or gitlabs, and no other git option. So, yeah, totally get what you state there!
the former issue and patch tracker was kept active until January 1st, 2026, when Codeberg issues and pull requests became the only supported mechanisms
This part I don't understand. If a significant number of contributors don't like the new flow, why make them switch? Is there some hidden cost to allowing multiple flows? Why make it one-size-fits-all?
The quality of service achieved by the Codeberg e.V. employees and volunteers has been very good and the occasional downtime was usually short and clearly communicated.
Nit pick: I don't think Codeberg has multiple paid employees; afaict it's just one. Edit: turns out they added their second employee last December.
Wow, this is a surprisingly interesting, educative, insightful - and also well written - post!
Apart from the AGit workflow others already mentioned, the GCD community process and some in-progress thoughts on it are also super interesting to me!