← back

Gentoo on Codeberg

todsacerdoti | 2026-02-17 17:21 UTC | source

Codeberg logo

Gentoo now has a presence on Codeberg, and contributions can be submitted for the Gentoo repository mirror at https://codeberg.org/gentoo/gentoo as an alternative to GitHub. Eventually also other git repositories will become available under the Codeberg Gentoo organization. This is part of the gradual mirror migration away from GitHub, as already mentioned in the 2025 end-of-year review. Codeberg is a site based on Forgejo, maintained by a dedicated non-profit organization, and located in Berlin, Germany. Thanks to everyone who has helped make this move possible!

These mirrors are for convenience for contribution and we continue to host our own repositories, just like we did while using GitHub mirrors for ease of contribution too.

Submitting pull requests

If you wish to submit pull requests on Codeberg, it is recommended to use the AGit approach as it is more space efficient and does not require you to maintain a fork of gentoo.git on your own Codeberg profile. To set it up, clone the upstream URL and check out a branch locally:

git clone git@git.gentoo.org:repo/gentoo.git
cd gentoo
git remote add codeberg ssh://git@codeberg.org/gentoo/gentoo
git checkout -b my-new-fixes

Once you’re ready to create your PR:

git push codeberg HEAD:refs/for/master -o topic="$title"

and the PR should be created automatically. To push additional commits, repeat the above command - be sure that the same topic is used. If you wish to force-push updates (because you’re amending commits), add “-o force-push=true” to the above command.

More documentation can be found on our wiki.

262 points | 92 comments | original link

Comments

cadamsdotcom | 2026-02-17 18:13 UTC
Great to see important projects like Gentoo showing it can be done

This “Great Uncoupling” is well underway and will take us toward a less monocultural Internet.

simoncion | 2026-02-17 23:10 UTC
> This “Great Uncoupling” is well underway and will take us toward a less monocultural Internet.

Gentoo's Github mirrors have only been to make contributing easier for -I expect- newbies. The official repos have -AFAIK- always been hosted by the Gentoo folks. FTFA:

  This [work] is part of the gradual mirror migration away from GitHub, as already mentioned in the 2025 end-of-year review.

  These [Codeberg] mirrors are for convenience for contribution and we continue to host our own repositories, just like we did while using GitHub mirrors for ease of contribution too.
And from the end-of-year review mentioned in TFA [0]

  Mostly because of the continuous attempts to force Copilot usage for our repositories, Gentoo currently considers and plans the migration of our repository mirrors and pull request contributions to Codeberg. ... Gentoo continues to host its own primary git, bugs, etc infrastructure and has no plans to change that.
we learn that the primary reason for moving is Github attempting to force its shitty LLM onto folks who don't want to use it.

So yeah, the Gentoo project has long been "decoupled" or "showing it can be done" or whatever.

[0] <https://www.gentoo.org/news/2026/01/05/new-year.html>

mbreese | 2026-02-17 18:21 UTC
Is this the start of a more frequent code-migrations out of Github?

For years, the best argument for centralizing on Github was that this was where the developers were. This is where you can have pull requests managed quickly and easily between developers and teams that otherwise weren't related. Getting random PRs from the community had very little friction. Most of the other features were `git` specific (branches, merges, post-commit hooks, etc), but pull requests, code review, and CI actions were very much Github specific.

However, with more Copilot, et al getting pushed through Github (and now-reverted Action pricing changes), having so much code in one place might not be enough of a benefit anymore. There is nothing about Git repositories that inherently requires Github, so it will be interesting to see how Gentoo fares.

I don't know if it's a one-off or not. Gentoo has always been happy to do their own thing, so it might just be them, but it's a trend I'm hearing talked about more frequently.

JoshTriplett | 2026-02-17 18:35 UTC
I'm really looking forward to some form of federated forking and federated pull requests, so that it doesn't matter as much where your repository is.
holysoles | 2026-02-17 18:48 UTC
For those curious, the federation roadmap is here: https://codeberg.org/forgejo-contrib/federation/src/branch/m...

I'm watching this pretty closely, I've been mirroring my GitHub repos to my own forgejo instance for a few weeks, but am waiting for more federation before I reverse the mirrors.

Also will plug this tool for configuring mirrors: https://github.com/PatNei/GITHUB2FORGEJO

Note that Forgejo's API has a bug right now and you need to manually re-configure the mirror credentials for the mirrors to continue to receive updates.

bsimpson | 2026-02-17 19:09 UTC
I use GitHub because that's where PRs go, but I've never liked their PR model. I much prefer the Phabricator/Gerrit ability to consider each commit independently (that is, have a personal branch 5 commits ahead of HEAD, and be able to send PRs for each without having them squashed).

I wonder if federation will also bring more diversity into the actual process. Maybe there will be hosts that let you use that Phabricator model.

I also wonder how this all gets paid for. Does it take pockets as deep as Microsoft's to keep npm/GitHub afloat? Will there be a free, open-source commons on other forges?

mikepurvis | 2026-02-17 19:17 UTC
GitLab has been talking about federation at least between instances of itself for 8+ years: https://gitlab.com/groups/gitlab-org/-/epics/16514

Once the protocols are in place, one hopes that other forges could participate as well, though the history of the internet is littered with instances where federation APIs just became spam firehoses (see especially pingback/trackback on blog platforms).

okanat | 2026-02-17 19:22 UTC
I would love git-bug project[1] to be successful in achieving that. That way Git forges are just nice Web porcelain on top of very easy to migrate data.

[1] https://github.com/git-bug/git-bug

pocksuppet | 2026-02-17 19:23 UTC
So... git's original design
rtpg | 2026-02-17 23:23 UTC
I just want a forge to be able to let me push up commits without making a fork. Do the smart thing for me, I don't need a fork of a project to send in my patch!
VorpalWay | 2026-02-17 19:07 UTC
Arch Linux have used their own gitlab instance for a long time (though with mirrors to GitHub). Debian and Fedora have both run their own infra for git for a long time. Not sure about other distros. I was surprised Gentoo used GitHub at all.

Pretty sure several of these distros started doing this with cvs or svn way back before git became popular even.

Foxboron | 2026-02-17 19:30 UTC
I mean, gitlab is only from ~2019.

The first hit I could find of a git repository hosted on `archlinux.org` is from 2007; https://web.archive.org/web/20070512063341/http://projects.a...

encom | 2026-02-17 19:18 UTC
>code-migrations out of Github

I hope so. When Microsoft embraced GitHub there was a sizeable migration away from it. A lot of it went to Gitlab which, if I recall correctly, tanked due to the volume.

But it didn't stick. And it always irked me, having Microsoft in control of the "default" Git service, given their history of hostility towards Free software.

toastal | 2026-02-17 19:33 UTC
Coincidentally, my most-used project is on Codeberg, & is a filter list (such as uBlock Origin) for hiding a lot Microsoft GitHub’s social features, upsells, Copilot pushes, & so on to try to make it tolerable until more projects migrate away <https://codeberg.org/toastal/github-less-social>.
tiffanyh | 2026-02-17 19:54 UTC
I really like @mitchellh perspective on this topic of moving off GitHub.

---

> If you're a code forge competing with GitHub and you look anything like GitHub then you've already lost. GitHub was the best solution for 2010. [0]

> Using GitHub as an example but all forges are similar so not singling them out here This page is mostly useless. [1]

> The default source view ... should be something like this: https://haskellforall.com/2026/02/browse-code-by-meaning [2]

[0] https://x.com/mitchellh/status/2023502586440282256#m

[1] https://x.com/mitchellh/status/2023499685764456455#m

[2] https://x.com/mitchellh/status/2023497187288907916#m

blibble | 2026-02-17 20:23 UTC
for [1] he's right for his specific use case

when he's working on his own project, obviously he never uses the about section or releases

but if you're exploring projects, you do

(though I agree for the tree view is bad for everyone)

Starlevel004 | 2026-02-17 21:06 UTC
Person who pays for AI: We should make everything revolve around the thing I pay for
bastardoperator | 2026-02-17 22:15 UTC
rtpg | 2026-02-17 23:22 UTC
I really don't get this... like you're a code checkout away from just asking claude locally. I get that it is a bit more extra friction but "you should have an agent prompt on your forge's page" is a _huge_ costly ask!

I say this as someone who does browse the web view for repos a lot, so I get the niceness of browsing online... but even then sometimes I'm just checking out a repo cuz ripgrep locally works better.

pojntfx | 2026-02-18 00:03 UTC
Aren't they literally moving off GitHub _because_ of LLMs and the enshittification optimising for them causes? This line of thinking and these features seem to push people _off_ your platform, not onto it.
hparadiz | 2026-02-18 01:05 UTC
This looks like a confusing mess to me.
Rapzid | 2026-02-18 02:06 UTC
Oh FFS. Twitter really brings out the worst in people. Prefer the more deeply insightful and measured blog posting persona.
resonious | 2026-02-18 02:12 UTC
The stuff he says in [1] completely does not match my usage. I absolutely do use fork and star. I use release. I use the homepage link, and read the short description.

I'm also quite used to the GitHub layout and so have a very easy time using Codeberg and such.

I am definitely willing to believe that there are better ways to do this stuff, but it'll be hard to attract detractors if it causes friction, and unfamiliarity causes friction.

jruz | 2026-02-17 20:00 UTC
I would say started with Zig.

For us Europeans has more to do with being local that reliability or copilot.

shevy-java | 2026-02-17 20:03 UTC
I hope so. Ever since Trump and the US corporations declared software-war against Europeans, I want to reduce all dependencies on US corporations as much as possible. Ideally to zero. Also hardware-wise. This will take a long time, but Canadians understood the problem domain here. European politicians still need to understand that Trump and his cronies changed things permanently.
kpcyrd | 2026-02-17 20:37 UTC
I moved one of my projects from Github to codeberg because Github can't deal with sha256 repositories, but codeberg can.
shmerl | 2026-02-18 02:33 UTC
It's been going on for a while. Recent AI craze just accelerates it.
iberator | 2026-02-17 18:32 UTC
codeberg is AMAZING and VERY VERY fast and snappy and EASY TO USE.

I REALLY recommend it

nubinetwork | 2026-02-17 21:15 UTC
Fast? I clicked on a random ebuild, then clicked history... the page took over 60 seconds to load a single commit. I could have done that faster locally, or even on github. /shrug
sethops1 | 2026-02-17 21:48 UTC
Codeberg was down for several hours over this past weekend. I want an alternative to GitHub as much as the next anti-big tech nerd, but let's not spread false narratives. Codeberg's uptime is probably a single nine right now, at best.
ashton314 | 2026-02-17 23:17 UTC
I mean… GitHub's uptime story has been getting worse…

I hear you and you're right that Codeberg has some struggles. If anyone needs to host critical infra, you're better off self-hosting a Forgejo instance. For personal stuff? Codeberg is more than good enough.

b00ty4breakfast | 2026-02-18 01:21 UTC
it may be a rock and a hard place situation; they need the resources to address these issues but folks aren't gonna move their giant, mission-critical code there if they don't address these issues.
ashton314 | 2026-02-17 23:15 UTC
For the doubters replying here, Codeberg really is on average faster than GitHub. It's great. Objective measurements here: https://forgeperf.org/

Codeberg does suffer from the occasional DDOS attack—it doesn't have the resources that GH has to mitigate these sorts of things. Also, if you're across the pond, then latency can be a bit of an issue. That said, the pages are lighter weight, and on stable but low-bandwith connections, Codeberg loads really quickly and all the regular operations are supper zippy.

ahartmetz | 2026-02-18 02:29 UTC
What I think after looking at these numbers is that we need to take the nuclear option - a native (no web stack at all) code review client. Seconds (times 100 or so for one larger review) are not in any way an acceptable order of magnitude to discuss performance of a front-end for editing tens of kilobytes of text. And the slow, annoying click orgy to fold out more common code, a misfeature needed just to work around loading syntax-highlighted text being insanely slow. Git is very fast, text editing is very fast, bullshit frameworks are slow.

I don't think that it would take great contortions to implement a HTML + JS frontend that's an order of magnitude faster than the current crapola, but in practice it... just doesn't seem to happen.

xvilka | 2026-02-17 18:45 UTC
All everything aside, reviewing big pull requests on GitHub became nearly impossible - even with the simplest change view it makes you spend too much time on waiting for the page to load the necessary file first. The performance degraded significantly from what was the experience from 10 years ago. UI became an absolute mess. Maybe even vibe-coded.
arccy | 2026-02-17 19:37 UTC
They even have the gall to call it an improved UI for reviewing large pull requests. They must have let UI designers who've never written code before design it.
shimman | 2026-02-17 19:43 UTC
IME those types of UI designers are way way way way more common, very few designers seem to understand the platform they are designing on and care more about aesthetics rather than proper platform designs.
bflesch | 2026-02-17 19:52 UTC
That's what happens when the whole company uses high-end macbooks and nobody has an older PC. It's been noted thousands of times on HN but these US companies make money head over fist and do not give a single damn about people on "lower" end devices.
bjackman | 2026-02-17 20:13 UTC
Is there a good code review tool out there? The best one I've used is Gerrit, at least it has a sensible design in principle. Aside from that I've only used GitHub and Gitlab which both seem like toys to me. (And mailing lists, lol).

But the implementation of Gerrit seems rather unloved, it just seems to get the minimal maintenance to keep Go/Android chooching along, and nothing more.

seabrookmx | 2026-02-17 22:56 UTC
My old job used Gerrit, and new job uses Gitlab. I really miss the information density and workflow of Gerrit. We enforce fast forward merges and squashing for MR's anyways, so we just have an awkward version of what Gerrit does by default.

Gitlab CI is good but we use local (k8s-hosted) runners so I have to imagine there's a bunch of options that provide a similar experience.

Intralexical | 2026-02-17 23:51 UTC
What do people think of ReviewBoard?
maccard | 2026-02-18 00:59 UTC
We use perforce in work, and we use p4 swarm. It’s unremarkable, hasn’t changed in a decade and just works. Best part of perforce, by far
viraptor | 2026-02-17 20:32 UTC
While I'm not annoyed by the slowdown that much, what made me not trust them anymore is being careless with the system. For example I did a review recently on a PR where the collapsing sections were not visible and made 2 patch fragments look like continuous code. I commented that this makes no sense and won't run... only to look like an idiot later. Fortunately the issue was fixed by the time I looked at the PR again, but still, much less trust now.
razighter777 | 2026-02-17 21:09 UTC
Quick tip: If you type .patch after the PR url it gives you a git patch. Do curl <github patch> | git am and you can apply and review it locally.
IshKebab | 2026-02-17 22:23 UTC
No need for that. Just install the VSCode GitHub extension and you can just directly open them. It even supports comments.

Hell even if you don't use VSCode there are much better options than messing around with patch files.

ahartmetz | 2026-02-18 02:16 UTC
Heck, you can't - to the best of my knowledge - even comment on changes in a commit instead of just the sum total of changes in a pull request. It's as if GitHub expects everyone to use squash on merge workflows, which is insane for developers who know how to structure commits and write commit messages. Oh yeah, and you can't comment on commit messages neither. In Gerrit (which otherwise has plenty of problems, too), they show up as part of the patch.
positron26 | 2026-02-17 19:24 UTC
The reality of good competition is that competitors are built on good, cheap open source. No matter how decentral, a lot of users will want guards at the offramps and onramps. The only path for... everyone to create stronger competitive checks on services they rely on is to make sure that the open foundations are extremely strong.

The alliance any up-and-comers can make with the ecosystem is to develop more of what they host in the open source. In return for starting much closer to the finish line, we only ask that they also make the lines closer for those that come after them.

That's a bit of an indirect idea for today's Joe Internet. Joe Internet is going to hold out waiting for such services to be offered entirely for free, by a magical Github competitor who exists purely to serve in the public interest. Ah yes, Joe Internet means government-funded, but of course government solutions are not solutions for narrow-interest problems like "host my code" that affect only a tiny minority. And so Joe Internet will be waiting for quite some time.

carefree-bob | 2026-02-18 00:07 UTC
The problem is funding. To be a real github competitor you need some serious infrastructure investment, which means you need to generate revenue and you start doing all sorts of stuff that is hostile to your free-tier userbase.

Personally I wouldn't mind paying for access but I doubt there is a critical mass of users that can be weaned off of free access. Competing with free networks is hard. Codeberg, as far as I can tell, basically has a donation model where you can volunteer to pay and be a "member", but 0.5% of users choose that option, that is, they made a one time payment of 10 euros. That's enough to fund how many months of bandwidth and a couple of recycled servers. For cloud infrastructure standards are pretty high, you want replication, backup, anti-DDOS, monitoring, etc. All of that costs money. It would also help if they made it easier to donate with a paypal link instead of a SEPA QR code that requires an international bank transfer.

cbarrick | 2026-02-17 19:31 UTC
I was familiar with the Gerrit workflow, but not the AGit workflow.

The original AGit blog post is no longer available, but it is archived: https://web.archive.org/web/20260114065059/https://git-repo....

From there, I found a dedicated Git subcommand for this workflow: https://github.com/alibaba/git-repo-go

I really like what I've read about AGit as a slightly improved version of the Gerrit workflow. In particular, I like that you can just use a self-defined session ID rather than relying on a commit hook to generate a Gerrit ChangeId. I would love to see Gerrit support this session token in place of ChangeIds.

eddd-ddde | 2026-02-17 19:53 UTC
I prefer the Gerrit workflow over any other git-based workflow, specially since it seems to be going the Jujutsu route in the future: https://www.gerritcodereview.com/design-docs/support-jujutsu...
joecool1029 | 2026-02-17 19:49 UTC
So I've started to use it since that's the way things are going. It's pretty drop-in compatible with how I used to use Github contributions for Gentoo. There are currently 2 downsides I'm facing:

- It's slow for git command-line tasks, despite the site UX being much faster, git operations are really slow compared to Github.

- It doesn't have full feature parity with Github actions. Their CI doesn't run a full pkgcheck I guess, so it's still safer for a new Gentoo contributor to submit PR's to github until that gets addressed.

shevy-java | 2026-02-17 20:02 UTC
That's good. I am getting very annoyed at how US-dependent Europeans have become, ever since Trump keeps on threatening us non-stop. The Canadians understood the issue; European politicians are WAY too slow. There is a reason why Trump is also known as Agent Krasnov. Yuri Bezmenov predicted this in the 1980s; he literally explaind the "Flood the zone with shit" tactic, which is a KGB strategy (or, even older than the KGB). Steve Bannon only steals stuff; his mind is unable to devise anything on his own.

I have not used Codeberg that much myself. I have known about it, but the UI is a bit ... scary. Gitlab also has a horrible UI. It is soooo strange that github is the only one that got UI right. Why can't the others learn from KEEPING THINGS SIMPLE?

ahartmetz | 2026-02-18 02:31 UTC
I find GitLab and GitHub to be very similarly bad-to-barely-acceptable.
frostworx | 2026-02-17 20:20 UTC
mmh, maybe the perfect time to leave github aswell and return to gentoo.
bramhaag | 2026-02-17 20:30 UTC
I really enjoy using Codeberg (as well as my own self-hosted Forgejo instance). It's fast and responsive, and if something is broken or inconsistent, it's trivial to create a PR and get it merged with minimal friction. It's a breath of fresh air after having dealt with GitHub's bs for many years.