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.
I also check for the License of a project when I'm looking at a project for the first time. I usually only look at that information once, but it should be easily viewed.
I also look for releases if it's a program I want to install... much easier to download a processed artifact than pull the project and build it myself.
But, I think I'm coming around to the idea that we might need to rethink what the point of the repository is for outside users. There's a big difference in the needs of internal and external users, and perhaps it's time for some new ideas.
(I mean, it's been 18 years since Github was founded, we're due for a shakeup)
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.
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.
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).
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?
That's effectively what I do. I have my dev branch, and then I make separate branches for each PR with just the commit in it. Works well enough so long as the commits are independent, but it's still a pain in the ass to manage.
Personally, I'd like to go the other way: not just that PRs are the unit of contribution, but that rebased PRs are a first-class concept and versioning of the changes between entire PRs is a critical thing to track.
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.
No. Git is not a web-based GUI capable of managing users and permissions, facilitating the creation and management of repositories, handling pull requests, handling comments and communication, doing CI, or a variety of other tasks that sites like Codeberg and Forgejo and GitLab and GitHub do. If you don't want those things, that's fine, but that isn't an argument that git subsumes them.
People were doing that by using additional tools on top of git, not via git alone. I intentionally only listed things that git doesn't do.
There's not much point in observing "but you could have done those things with email!". We could have done them with tarballs before git existed, too, if we built sufficient additional tooling atop them. That doesn't mean we have the functionality of current forges in a federated model, yet.
That doesn't cover tracking pull requests, discussing them, closing them, making suggestions on them...
Those exist (badly and not integrated) as part of additional tools such as email, or as tasks done manually, or as part of forge software.
I don't think there's much point in splitting this hair further. I stand by the original statement that I'd love to see federated pull requests between forges, with all the capabilities people expect of a modern forge.
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>.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Large GitHub PRs are miserably slow even with a maxed out Mac Studio on gigabit fiber with single-digit ms ping to their server. It’s not an example of something that works well on high-end hardware but scales down poorly.
> 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.
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.
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.
Codeberg is one of my favourite Git hosting services. It is (to me) what GitHub should have remained like. I have been mirroring most of my GitHub projects to Codeberg as well. Someday when I can afford the time, I might decide to make Codeberg my primary repository hosting service and GitHub the mirror.
Many European software companies are looking for alternatives outside the US now with the geopolitical situation between the US and EU. It's not only limited to the three big cloud providers, but Microsoft in general, in addition to other US providers.
For all the negativity on github I will praise them for one really good feature - code search across an organisation. I've found it really useful particularly for 'platform' related changes to be able to find how other people in an org has solved a problem. It's particularly useful when the documentation only shows the happy path (or was written 5 years ago and 'oh nobody does it that way anymore')
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?
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.
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
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.
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.
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.
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
Person who pays for AI: We should make everything revolve around the thing I pay for
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)
I also check for the License of a project when I'm looking at a project for the first time. I usually only look at that information once, but it should be easily viewed.
I also look for releases if it's a program I want to install... much easier to download a processed artifact than pull the project and build it myself.
But, I think I'm coming around to the idea that we might need to rethink what the point of the repository is for outside users. There's a big difference in the needs of internal and external users, and perhaps it's time for some new ideas.
(I mean, it's been 18 years since Github was founded, we're due for a shakeup)
Crazy... https://github.com/ghostty-org/ghostty
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.
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.
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).
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?
> and be able to send PRs for each without having them squashed
Can't you branch off from their head and cherry-pick your commits?
That's effectively what I do. I have my dev branch, and then I make separate branches for each PR with just the commit in it. Works well enough so long as the commits are independent, but it's still a pain in the ass to manage.
Personally, I'd like to go the other way: not just that PRs are the unit of contribution, but that rebased PRs are a first-class concept and versioning of the changes between entire PRs is a critical thing to track.
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
So... git's original design
No. Git is not a web-based GUI capable of managing users and permissions, facilitating the creation and management of repositories, handling pull requests, handling comments and communication, doing CI, or a variety of other tasks that sites like Codeberg and Forgejo and GitLab and GitHub do. If you don't want those things, that's fine, but that isn't an argument that git subsumes them.
Git was published with compatibility with a federated system supporting almost all of that out of the box - email.
Sure, the world has pretty much decided it hates the protocol. However, people _were_ doing all of that.
People were doing that by using additional tools on top of git, not via git alone. I intentionally only listed things that git doesn't do.
There's not much point in observing "but you could have done those things with email!". We could have done them with tarballs before git existed, too, if we built sufficient additional tooling atop them. That doesn't mean we have the functionality of current forges in a federated model, yet.
`git send-email` and `git am` are built into Git, not additional tools.
That doesn't cover tracking pull requests, discussing them, closing them, making suggestions on them...
Those exist (badly and not integrated) as part of additional tools such as email, or as tasks done manually, or as part of forge software.
I don't think there's much point in splitting this hair further. I stand by the original statement that I'd love to see federated pull requests between forges, with all the capabilities people expect of a modern forge.
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>.
I would say started with Zig.
For us Europeans has more to do with being local that reliability or copilot.
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.
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.
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...
Gitlab started in 2011. Which, granted, is still after 2007.
https://www.ycombinator.com/companies/gitlab
I moved one of my projects from Github to codeberg because Github can't deal with sha256 repositories, but codeberg can.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Large GitHub PRs are miserably slow even with a maxed out Mac Studio on gigabit fiber with single-digit ms ping to their server. It’s not an example of something that works well on high-end hardware but scales down poorly.
Well we started moving off the cloud. It is a lot easier then most people think. And yes Codeberg will most likely replace github for us too.
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.
> 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:
And from the end-of-year review mentioned in TFA [0] 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>
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.
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.
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...
Codeberg is one of my favourite Git hosting services. It is (to me) what GitHub should have remained like. I have been mirroring most of my GitHub projects to Codeberg as well. Someday when I can afford the time, I might decide to make Codeberg my primary repository hosting service and GitHub the mirror.
If you haven't seen it already, Codeberg is seeking donations here: <https://docs.codeberg.org/improving-codeberg/donate/>. A good way to support a product you like rather than becoming the product yourself.
Many European software companies are looking for alternatives outside the US now with the geopolitical situation between the US and EU. It's not only limited to the three big cloud providers, but Microsoft in general, in addition to other US providers.
Forgejo is so nice, been hosting it locally for my projects for a year or so
For all the negativity on github I will praise them for one really good feature - code search across an organisation. I've found it really useful particularly for 'platform' related changes to be able to find how other people in an org has solved a problem. It's particularly useful when the documentation only shows the happy path (or was written 5 years ago and 'oh nobody does it that way anymore')
Is that a unique feature to GitHub?
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?
I am also moving my "important for me" projects to Codeberg.
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.
mmh, maybe the perfect time to leave github aswell and return to gentoo.
codeberg is AMAZING and VERY VERY fast and snappy and EASY TO USE.
I REALLY recommend it
[delayed]
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
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.
[delayed]
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.