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'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).
Gitlab has also indicated not to be interested as a company to develop this themself, and esp. not given all the other demands they get from their customer base. The epic you refer to had been closed for this reason, but was later reopened for the sake of the community. For there to be federation support in self-hosted Gitlab instances, a further community effort is needed, and right now AFAIK no one is actively working on any ActivityPub related user stories.
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?
Unless I misunderstood your workflow Forgejo Agit approach mentioned in OP might already cover that.
You can push any ref not necessarily HEAD. So as long as you send commit in order from a rebase on main it should be ok unless I got something wrong from the doc?
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.
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.
That’s the trick in your system — all commits have to be completely independent. Generally mine aren’t, so unless we want to review each minor commit, they get squashed.
I can see merit in your suggestion, but it does require some discipline in practice. I’m not sure I could do it.
The way Gerrit handles this is to make a series of PR-like things that are each dependent on the previous one. The concept of "PR that depends on another PR" is a really useful one, and I wish forges supported it better.
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!
Right. GitHub started as and still is that "social coding platform" from 2008 inspired by the then-novel growth hacking of that era understood and demonstrated by Facebook—where it wasn't enough to host, say, your user's LiveJournal blog, and their friends might sign up if they wanted, and that was that. No, rather, you host your users' content but put it inside a closed system where you've erected artificial barriers that make it impossible to do certain things unless those friends are actively using the platform, too.
GitHub could have been project hosting and patch submission. It's the natural model for both the style of contributions that you see most on GitHub today and how it's used by Linux. (Pull requests are meant for a small circle of trusted collaborators that you're regularly pulling from and have already paid the one-time cost to set up in your remotes—someone is meant to literally invoke git-pull to get a whole slew of changes that have already been vetted by someone within the circle of frequent collaborators—since it is, after all, already in their tree—and anyone else submits patches.) Allowing simple patch submission poses a problem, though, in that even if Alice chooses to host projects on GitHub, then Bob might decide Gitorious is better and host stuff there even while remaining friendly and sending patches to Alice's GitHub-hosted project. By going with a different, proprietary pull request system and forcing a clunky forking workflow on Alice and Bob, on the other hand, you can enforce where the source of the changes are coming from (i.e. another repo hosted on GitHub). And that's what they did.
I’m speculating here, but I think this is at least a plausible explanation. There is no guarantee that the pull request will be accepted. And the new commit has to live somewhere. When you require a fork, the commit is stored in the submitter’s version. If you don’t require the fork, the commit is stored somewhere in the main project repository. Personally, this is something I’d try to avoid.
I don’t know how the Agit-flow stores the commit, but I assume it would have to be in the main repo, which I’m happy to not be used for random PRs.
Requiring forks makes it more convoluted for simple quick pushes, but I can see why it would be done this way.
I suspect the real answer is that’s the way Linux is developed. Traditionally, the mai developers all kept their own separate branches that would be used track changes. When it was time for a new release, the appropriate commits would then be merged into the main repository. For large scale changes, having separate forks makes sense — there is a lot to track. But, it does make the simple use-case more difficult. Git was designed to make the complex use-cases possible, sometimes at the expense of usability for simpler use cases.
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.
I think people (especially those who joined the internet after the .com bubble) underestimate the level of decentralization and federation coming with the old-school (pre web-centric mainframe-like client mentality) protocols such as email and Usenet and maybe even IRC.
Give me “email” PR process anytime. Can review on a flight. Offline. Distraction free. On my federated email server and have it work with your federated email server.
And the clients were pretty decent, at running locally. And it still works great for established projects like Linux Kernel etc.
It’s just pain to set up for a new project, compared to pushing to some forge. But not impossible. Return the intentionality of email. With powerful clients doing threading, sorting, syncing etc, locally.
I'm older than the web. I worked on projects using CVS, SVN, mercurial, git-and-email, git-with-shared-repository, and git-with-forges. I'll take forges every time, and it isn't even close. It's not a matter of not having done it the old way, it's a matter of not wanting to do it again.
I guess we might have opposite experiences. Part of which I understand - the society moved on, the modern ways are more mature and developed… but I wonder how much of that can be backported without handing over to the centralized systems again.
The advantage of old-school was partially that the user agents, were in fact user agents. Greasemonkey tried to bridge the gap a bit, but the Web does not lend itself to much user-side customization, the protocol is too low level, too generic, offering a lot of creative space to website creators, but making it harder to customize those creations to user’s wants.
I'm older than the trees, but, younger than the mountains! Email all day, all the way. Young people are very fascinated and impressed by how much more I can achieve, faster, with email, compared with their chats, web 3.0 web interfaces, and other crap.
Yes, it takes time to learn, but that is true for anything worthwhile.
What I like about git-and-email-patches is the barrier to entry.
I think it's dwm that explicitly advertises a small and elitist userbase as a feature/design goal. I feel like mailing lists as a workflow serve a similar purpose, even if unintentionally.
With the advent of AI slop as pull request I think I'm gravitating to platforms with a higher barrier to entry, not lower.
What is a forge? What is a modern forge? What is a pull request?
There is code or repository, there is a diff or patch. Everything else your labeling as pull request is unknown, not part of original design, debatable.
GitHub style pull request is not part of the original design.
What aspects and features you want to keep, and what exactly you say many others are interested in?
We don't even know what a forge is. Let alone a modern one.
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>.
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.
The amount of inference required for semantic grouping is small enough to run locally. It can even be zero if semantic tagging is done manually by authors, reviewers, and just readers.
Where did "AI for inference" and "semantic tagging" come from in this discussion? Typically for code repositories - AIs/LLMs are doing reviews/tests/etc, not sure what/where semantic tagging fits? Even do be done manually by humans.
And besides that - have you tried/tested "the amount of inference required for semantic grouping is small enough to run locally."?
While you can definitely run local inference on GPUs [even ~6 years old GPUs and it would not be slow]. Using normal CPUs it's pretty annoyingly slow (and takes up 100% of all CPU cores). Supposedly unified memory (Strix Halo and such) make it faster than ordinary CPU - but it's still (much) slower than GPU.
I don't have Strix Halo or that type of unified memory Mac to test that specifically, so that part is an inference I got from an LLM, and what the Internet/benchmarks are saying.
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.
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.
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)
Hrm. Mitchell has been very level-headed about AI tools, but this seems like a rare overstep into hype territory.
"This new thing that hasn't been shipped, tested, proven, in a public capacity on real projects should be the default experience going forwards" is a bit much.
I for one wouldn't prefer a pre-chewed machine analysis. That sounds like an interesting feature to explore, but why does it need to be forced into the spotlight?
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.
Find a project, find out if it's the original or a fork, and either way, find all the other possibly more relevant forks. Maybe the original is actually derelict but 2 others are current. Or just forks with significant different features, etc. Find all the oddball individual small fixes or hacks, so even if you don't want to use someone's fork you may still like to pluck the one change they made to theirs.
I was going to also say the search but probably that can be had about the same just in regular google, at least for searching project names and docs to find the simple existence of projects. But maybe the code search is still only within github.
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.
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.
At the time I (and many others) had a much more positive view of Microsoft. In 2018 Nadella was bringing a lot of positive change to Microsoft. The release of VSCode and WSL among the more visible trends that signaled a new direction. A world in which Microsoft wasn't the preferred owner of Github, but could at least be a good steward and an open-source friendly company.
Now in 2026 things look different. While the fears that Microsoft would revert to 90s Embrace, Extend, Extinguish mostly haven't come to pass, their products are instead all plagued by declining quality and stability, and a product direction that seems to willfully ignore most of the user base
Yes, you are right. I read a lot about European FOSS projects (and my own blog is member of a planet for german Foss articles). Migrating away from github has been a topic for a while in that scene now. First just because github is not Foss, then accelerated because of Microsoft, and Microsoft now mismanaging Github with ai bullshit accelerated it even more. Plus the push for independence of us services, Trumps imperialism is a big factor as well.
So absolutely not the start of the movement, but it seems to be accelerating more and more.
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.
> But the implementation of Gerrit seems rather unloved
There are lots of people who are very fond of Gerrit, and if anything, upstream development has picked up recently. Google has an increasing amount of production code that lives outside of their monorepo, and all of those teams use Gerrit. They have a few internal plugins, but most improvements are released as part of the upstream project.
My company has been using it for years, it's a big and sustained productivity win once everyone is past the learning curve.
Gerritforge[0] offers commercial support and runs a very stable public instance, GerritHub. I'm not affiliated with them and not a customer, but I talk to them a lot on the Gerrit Discord server and they're awesome.
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.
Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master.
Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history.
This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff.
If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
You can "chain" them and there's some native support for this in Gitlab, but I can't say I've ever tried using it. If I really need a feature branch, I just create a separate branch and target my MR's to that until the whole thing is ready to land in main. Again, it seems less natural to me than how Gerrit does it.
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.
VSCode is not a “given” - I certainly don’t use, or ever intend to use, it.
Patch files are excellent for small diffs at a glance. Sure, I can also `git remote add coworker ssh://fork.url` and `git diff origin/main..coworker/branch`, and that would even let me use Difftastic (!), but the patch is entirely reasonable for quick glances of small branch diffs.
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.
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.
Before everyone jumps on CodeBerg, please remember it runs on donations! It doesn't have Micro$lop money behind. Please donate to projects like this :)
This can have pros and cons. They will get much more vcpu / dollar on bare metal. And they can develop great operational discipline if they do it right.
On the downside, I don’t see them yet taking ops seriously. They are getting a lot of attention, but not yet establishing SLAs (at least not publicly). And their donations don’t seem to be scaling to the continued and expected demand.
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 love LibreOffice. It's fantastic. I rolled it out to a prior employer where everyone needed a word processor but we certainly didn't need to pay Office prices when we didn't have requirements that only Office could satisfy. A high point was when we were having trouble collaborating on a DOCX file with a customer, then they sheepishly told us that they weren't using Office, but this other LibreOffice (OO.org at the time) thing. We laughed and told them we were, too. That day we started swapping ODT files instead and everything worked 100x better.
And all that said, I haven't seen LibreOffice in person in years. Mac shops uses Pages & friends for internal stuff, but really, almost everyone not using Office 365 or whatever they're calling it now is using Google Docs. Google is eating Microsoft's lunch in this space, and my gut estimate is that they split 95+% of the office software market between them.
I do wish that weren't the case, but my personal experience tells me it is. I wish it were more common, and also that there was a virtuous cycle where more Mac users made it get more attention, and more attention made it feel more like a "Mac-assed Mac app", and feeling more like a Mac-assed Mac app got it more users, etc. I just don't see that playing out.
Countries in Europe realized that if USA sanctions International Criminal Court judge - that judge suddenly loses access to their email/calendar/docs/etc because Microsoft/Google/etc have to comply.
This one misses the point entirely, I'm sorry to say. Microsoft 365's "lunch" is that a majority of US businesses, schools, and governments are reliant on 365 for anything in their organization to function.
And also majority of European businesses and governments and schools. Europe is well integrated into US. Quite a few STOXX 600 have US wings or acquired US companies.
Basically a substantial (non-software) enginerring or financial work is done in Microsoft's proprietary formats, occasionaly involving VBA.
Many businesses cannot even pay salaries without macro-ridden Excel documents.
With 365 Microsoft has even stronger moat: cloud integrated co-editing using desktop apps. No browser will exceed C++/C# Office apps running directly on the PC. Not even proprietary apps have equivalent experience.
On top of that add all Azure, SharePoint etc. All big companies without exception use those and put significant portion of their business knowledge on Microsoft platforms.
US can literally kill Europe by just forcing Microsoft to shutdown its operations. It is fucking scary.
> 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.
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.
More power to them. But donations can’t possibly scale to the demand. They are already having significant capacity issues as evidenced to response time spikes throughout the week.
It’s a great hobby app, and the forgejo software seems well assembled, but Codeberg needs to be a bit more forthcoming about their capacity before more large projects move over.
I want to see larger projects like Gentoo migrate, but everything will come grinding to a halt if codeberg doesn’t come up with scalable resourcing (money & capacity)
they have a lot of options for sales. they can sell their service and run a not-for-profit enterprise.
surviving on online donations is extremely rare. In their case, they are not getting that many impressions, so $1-$5 donations won't cover their expenses. Think of how expensive even a single customer like Gentoo would be if they fully migrated -- how many Gentoo contributors would have to contribute money to cover Gentoo hosting.
I'm sure they have a sales pipeline planned, and similar to Facebook, they don't want to kill the buzz with sales before they build their audience.
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 stand corrected (thanks Sam): This was previously the case before they made the announcement, it’s fully working now. Feel free to contribute on Codeberg.
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')
The unified search (org wide, across issues/prs/code) and custom search backend works really well.
Honestly I don't understand all the GitHub hate recently. Honestly seems like a fashionable trend. Virtue signaling.
There was a decade where they barely innovated. Maybe people forgot about that? Or maybe they are too young to remember? I'll gladly take all the advances over the past 8-ish years for the odd issue they have. GH actions has evolved A LOT and I'm a heavy Copilot user at the org/enterprise level..
The raft of outages lately (my company was disrupted by I think four last week?) have certainly (and deservedly) created some pent-up frustration. I'm personally frustrated with its poor performance on Safari.
Overall, though, it's ... fine. That's all. A little worse than it used to be, which is frustrating, but certainly nowhere near unusable. I stood up my own forge and mirror some repos to it. The performance is almost comically better. I know it's not a fair comparison: I have only one user. On the other hand, I'm on a 9-year-old Xeon located geographically farther from me than GitHub's servers.
I'm largely happy with GitHub though for public GitHub at least, search is now terrible - it doesn't seem to return anything when not logged in and if you are logged in the filtering options are limited (this was the case mid last year anyway - maybe it's improved but I've given up trying to use the web search).
Whatever the motivations are, at least the end result is moving to freer (non-proprietary) and sometimes self-hosted solutions. If virtue signaling is what it takes to get there, I would like more of it. Virtue signaling gave us quality universities and museums, after all...
No, Gitlab has it too (don't know about the others offerings). Gitlab integrates Advanced Search via Elasticsearch, last I checked they had plans to make zoekt available as an alternative.
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.
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.
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.
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.
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.
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.
This is completely untrue. Git is fully decentralized in the way it's designed. People use it in a centralized manner, but that has nothing to do with the tool itself.
If you familiarize yourself with the way people use it for Linux kernel development, you'll see that it doesn't have to be this way.
There is an entire ecosystem of products that have locked themselves (and their users) into Github for one reason or another. I hope a critical mass builds that forces them to open up to a wider range of alternatives.
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?
Anyone with a brain can see that Github will have to be enshittified at scale with the pressure created from AI Code and everything generation. These guys are just getting ahead of the curve
What we reallt need is a place for secure hosting, one where AI is gatekept. Right now the big AI companies just steal code and no one does anything about it. Its pure theft. A blatant violation of copyright.
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.
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.
Maybe we need a display that just shows each user approximately what they cost.
Not a wikipedia banner. No guilt verbiage. No unrelatable total site/year numbers like "2.6M out of 5M goal" etc.
Just like some little bit of ui in a corner somewhere that passively just sits there and shows it's state like a red/yellow/green light or a battery meter or something. And what it shows is some at-a-glance representation of what you are costing the service, positive or negative.
If the org is open and low profit or even non profit, or even reasonable profit but organized as a co-op, this can be a totally honest number, which will probably be suprisingly small.
(and if any full-profit type services don't like having that kind of info made quite so public because it makes it hard to explain their own prices, well golly that sure sounds awful)
This will obviously have no effect on some people.
But I know that something like that will absolutely eat at some people until they decide they will feel better if they make that dot turn green.
And everyone else who just wants to take something for free and doesn't like being reminded of it, has no basis for complaining or claiming to be outraged at being nagged or browbeaten. It's a totally passive out of the way bit of display making no demands at all and not even hindering or speedbumping anything.
Even when you click on it for more info and the links to how to donate etc, the verbiage is careful not to make kids or drive-by laypeople or anyone else without real means feel bad or feel obligated. We don't need your soup money, don't sweat it.
Maybe even include some stories about how we all wound up in our high paying IT jobs because of the availability of stuff other people wrote and let us use for free when we were kids or former truck drivers etc, and so that's how you can understand and believe we really are ok with you now using this for free.
Can't possibly get any lighter touch than that.
And yet the fact that the little thing is just there all the time in view, that alone will make it like a voluntary itch that if you know you can afford it, you should make that light green. It's like a totally wholesome use of gamification psychology.
I guess it will also have to somehow show not just what you cost yourself, but also what all the non-paying users are costing and what your fraction of that would be to cover those. At least some payers would need to pay significantly more than what they cost.
But I'd be real curious to see just how bad that skew is after a while if a lot of individuals do end up paying at least for themselves, where today most of them pay nothing.
That may make the need for whales much reduced and really no whales, just a bunch that only pay like twice what they cost. Or even less, a heavy user that costs more might be able to totally cover the entire cost of 10 other light users with only 10% more than their own cost. It could eventually smooth out to being no real burden at all even for the biggest payers.
That's getting to be a bit much info to display all in a single colored dot or something without text or some complicated graphic, but I think this much could be shown and still be simple and elegant. Even a simple dot can have several dimensions all at once. size, hue, saturation, brightness, let alone any more detail like an outline or more complex shape.
About the only thing I can see that is a bad thing is I bet this is a recipe for unfairly taxing women more than men. You just know that far more women will make that light green even if it's not easy, and far more men will happily let it ride forever even though they could afford it effortlessly, just to spend that $3 on a half of a coffee instead.
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.
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'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).
Gitlab has also indicated not to be interested as a company to develop this themself, and esp. not given all the other demands they get from their customer base. The epic you refer to had been closed for this reason, but was later reopened for the sake of the community. For there to be federation support in self-hosted Gitlab instances, a further community effort is needed, and right now AFAIK no one is actively working on any ActivityPub related user stories.
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?
Unless I misunderstood your workflow Forgejo Agit approach mentioned in OP might already cover that.
You can push any ref not necessarily HEAD. So as long as you send commit in order from a rebase on main it should be ok unless I got something wrong from the doc?
https://forgejo.org/docs/latest/user/agit-support/
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.
> 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.
That’s the trick in your system — all commits have to be completely independent. Generally mine aren’t, so unless we want to review each minor commit, they get squashed.
I can see merit in your suggestion, but it does require some discipline in practice. I’m not sure I could do it.
Perhaps I'm missing something... If your commits are not all independent - I don't see how could they ever be pulled/merged independently?
The way Gerrit handles this is to make a series of PR-like things that are each dependent on the previous one. The concept of "PR that depends on another PR" is a really useful one, and I wish forges supported it better.
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!
This is supported on Codeberg (and Forgejo instances in general) via the "AGit workflow", see https://forgejo.org/docs/latest/user/agit-support/
Agreed. I assume there are reasons for this design choice though?
Presumably, the reasons are that it inflates the number of repositories, which is useful when showing numbers to investors.
Right. GitHub started as and still is that "social coding platform" from 2008 inspired by the then-novel growth hacking of that era understood and demonstrated by Facebook—where it wasn't enough to host, say, your user's LiveJournal blog, and their friends might sign up if they wanted, and that was that. No, rather, you host your users' content but put it inside a closed system where you've erected artificial barriers that make it impossible to do certain things unless those friends are actively using the platform, too.
GitHub could have been project hosting and patch submission. It's the natural model for both the style of contributions that you see most on GitHub today and how it's used by Linux. (Pull requests are meant for a small circle of trusted collaborators that you're regularly pulling from and have already paid the one-time cost to set up in your remotes—someone is meant to literally invoke git-pull to get a whole slew of changes that have already been vetted by someone within the circle of frequent collaborators—since it is, after all, already in their tree—and anyone else submits patches.) Allowing simple patch submission poses a problem, though, in that even if Alice chooses to host projects on GitHub, then Bob might decide Gitorious is better and host stuff there even while remaining friendly and sending patches to Alice's GitHub-hosted project. By going with a different, proprietary pull request system and forcing a clunky forking workflow on Alice and Bob, on the other hand, you can enforce where the source of the changes are coming from (i.e. another repo hosted on GitHub). And that's what they did.
I’m speculating here, but I think this is at least a plausible explanation. There is no guarantee that the pull request will be accepted. And the new commit has to live somewhere. When you require a fork, the commit is stored in the submitter’s version. If you don’t require the fork, the commit is stored somewhere in the main project repository. Personally, this is something I’d try to avoid.
I don’t know how the Agit-flow stores the commit, but I assume it would have to be in the main repo, which I’m happy to not be used for random PRs.
Requiring forks makes it more convoluted for simple quick pushes, but I can see why it would be done this way.
I suspect the real answer is that’s the way Linux is developed. Traditionally, the mai developers all kept their own separate branches that would be used track changes. When it was time for a new release, the appropriate commits would then be merged into the main repository. For large scale changes, having separate forks makes sense — there is a lot to track. But, it does make the simple use-case more difficult. Git was designed to make the complex use-cases possible, sometimes at the expense of usability for simpler use cases.
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
That's kind of the way Tangled works, right? Although it's Yet Another Platform so it's still a little bit locked in...
Have you seen https://tangled.org/
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.
I think people (especially those who joined the internet after the .com bubble) underestimate the level of decentralization and federation coming with the old-school (pre web-centric mainframe-like client mentality) protocols such as email and Usenet and maybe even IRC.
Give me “email” PR process anytime. Can review on a flight. Offline. Distraction free. On my federated email server and have it work with your federated email server.
And the clients were pretty decent, at running locally. And it still works great for established projects like Linux Kernel etc.
It’s just pain to set up for a new project, compared to pushing to some forge. But not impossible. Return the intentionality of email. With powerful clients doing threading, sorting, syncing etc, locally.
I'm older than the web. I worked on projects using CVS, SVN, mercurial, git-and-email, git-with-shared-repository, and git-with-forges. I'll take forges every time, and it isn't even close. It's not a matter of not having done it the old way, it's a matter of not wanting to do it again.
I guess we might have opposite experiences. Part of which I understand - the society moved on, the modern ways are more mature and developed… but I wonder how much of that can be backported without handing over to the centralized systems again.
The advantage of old-school was partially that the user agents, were in fact user agents. Greasemonkey tried to bridge the gap a bit, but the Web does not lend itself to much user-side customization, the protocol is too low level, too generic, offering a lot of creative space to website creators, but making it harder to customize those creations to user’s wants.
I'm older than the trees, but, younger than the mountains! Email all day, all the way. Young people are very fascinated and impressed by how much more I can achieve, faster, with email, compared with their chats, web 3.0 web interfaces, and other crap.
Yes, it takes time to learn, but that is true for anything worthwhile.
What I like about git-and-email-patches is the barrier to entry.
I think it's dwm that explicitly advertises a small and elitist userbase as a feature/design goal. I feel like mailing lists as a workflow serve a similar purpose, even if unintentionally.
With the advent of AI slop as pull request I think I'm gravitating to platforms with a higher barrier to entry, not lower.
What is a forge? What is a modern forge? What is a pull request?
There is code or repository, there is a diff or patch. Everything else your labeling as pull request is unknown, not part of original design, debatable.
Sorry to hear that you don't see the value in it. Many others do.
It's not what I meant.
GitHub style pull request is not part of the original design. What aspects and features you want to keep, and what exactly you say many others are interested in?
We don't even know what a forge is. Let alone a modern one.
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>.
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.
Both GitHub and now Codeberg are mirrors of a self-hosted cgit repository of Gentoo.
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
Many companies were using commercially licensed Gitlab in 2017 already, so it must have been established before that time. Definitely not in 2019
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
The amount of inference required for semantic grouping is small enough to run locally. It can even be zero if semantic tagging is done manually by authors, reviewers, and just readers.
Where did "AI for inference" and "semantic tagging" come from in this discussion? Typically for code repositories - AIs/LLMs are doing reviews/tests/etc, not sure what/where semantic tagging fits? Even do be done manually by humans.
And besides that - have you tried/tested "the amount of inference required for semantic grouping is small enough to run locally."?
While you can definitely run local inference on GPUs [even ~6 years old GPUs and it would not be slow]. Using normal CPUs it's pretty annoyingly slow (and takes up 100% of all CPU cores). Supposedly unified memory (Strix Halo and such) make it faster than ordinary CPU - but it's still (much) slower than GPU.
I don't have Strix Halo or that type of unified memory Mac to test that specifically, so that part is an inference I got from an LLM, and what the Internet/benchmarks are saying.
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.
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.
This looks like a confusing mess to me.
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)
Hrm. Mitchell has been very level-headed about AI tools, but this seems like a rare overstep into hype territory.
"This new thing that hasn't been shipped, tested, proven, in a public capacity on real projects should be the default experience going forwards" is a bit much.
I for one wouldn't prefer a pre-chewed machine analysis. That sounds like an interesting feature to explore, but why does it need to be forced into the spotlight?
Crazy... https://github.com/ghostty-org/ghostty
Oh FFS. Twitter really brings out the worst in people. Prefer the more deeply insightful and measured blog posting persona.
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.
I would say started with Zig.
For us Europeans has more to do with being local that reliability or copilot.
And the forks network display.
Find a project, find out if it's the original or a fork, and either way, find all the other possibly more relevant forks. Maybe the original is actually derelict but 2 others are current. Or just forks with significant different features, etc. Find all the oddball individual small fixes or hacks, so even if you don't want to use someone's fork you may still like to pluck the one change they made to theirs.
I was going to also say the search but probably that can be had about the same just in regular google, at least for searching project names and docs to find the simple existence of projects. But maybe the code search is still only within github.
I moved one of my projects from Github to codeberg because Github can't deal with sha256 repositories, but codeberg can.
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.
No, the start was a lot time ago.
It might also be a reflection of the number of frequent outages of GitHub under Microsoft recently and GitHub Copilot push
>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.
At the time I (and many others) had a much more positive view of Microsoft. In 2018 Nadella was bringing a lot of positive change to Microsoft. The release of VSCode and WSL among the more visible trends that signaled a new direction. A world in which Microsoft wasn't the preferred owner of Github, but could at least be a good steward and an open-source friendly company.
Now in 2026 things look different. While the fears that Microsoft would revert to 90s Embrace, Extend, Extinguish mostly haven't come to pass, their products are instead all plagued by declining quality and stability, and a product direction that seems to willfully ignore most of the user base
It's been going on for a while. Recent AI craze just accelerates it.
Yes, you are right. I read a lot about European FOSS projects (and my own blog is member of a planet for german Foss articles). Migrating away from github has been a topic for a while in that scene now. First just because github is not Foss, then accelerated because of Microsoft, and Microsoft now mismanaging Github with ai bullshit accelerated it even more. Plus the push for independence of us services, Trumps imperialism is a big factor as well.
So absolutely not the start of the movement, but it seems to be accelerating more and more.
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.
> But the implementation of Gerrit seems rather unloved
There are lots of people who are very fond of Gerrit, and if anything, upstream development has picked up recently. Google has an increasing amount of production code that lives outside of their monorepo, and all of those teams use Gerrit. They have a few internal plugins, but most improvements are released as part of the upstream project.
My company has been using it for years, it's a big and sustained productivity win once everyone is past the learning curve.
Gerritforge[0] offers commercial support and runs a very stable public instance, GerritHub. I'm not affiliated with them and not a customer, but I talk to them a lot on the Gerrit Discord server and they're awesome.
[0]: https://www.gerritforge.com/
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.
You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?
What do you mean by "stack" MRs?
Just like with plain git - in GitLab you can merge a branch that has multiple separate commits in it. And you can also merge (e.g. topical/feature) branches into one branch - and then merge that "combined" branch into main/master.
Though most teams/project prefer you don't stretch that route to the extreme - simply because it's PITA to maintain/sync several branches for a long period of time, resolving merge conflicts between branches that have been separate for a long time isn't fun, and people don't like to review huge diffs.
I guess what I'm saying is: for very large complex features, I don't want one big commit. I want to review a series of commits and then I want to have that series of commits persist in the history.
This is how Gerrit operates "natively" - the commit message and everything is part of the artifact under review exactly like the diff.
If the model is to squash an MR into a single commit before merging it, I'd then want to be able to have MRs that depend on each other.
You can "chain" them and there's some native support for this in Gitlab, but I can't say I've ever tried using it. If I really need a feature branch, I just create a separate branch and target my MR's to that until the whole thing is ready to land in main. Again, it seems less natural to me than how Gerrit does it.
I miss Gerrit - it was the first code review tool I used at work. Using GitHub and GitLab as subsequent jobs hasn't been fun.
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
What do people think of ReviewBoard?
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.
VSCode is not a “given” - I certainly don’t use, or ever intend to use, it.
Patch files are excellent for small diffs at a glance. Sure, I can also `git remote add coworker ssh://fork.url` and `git diff origin/main..coworker/branch`, and that would even let me use Difftastic (!), but the patch is entirely reasonable for quick glances of small branch diffs.
When I read
> No need for that.
I generally expect a less complex solution, it seems like your is more complex (easiness is arguable though)
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.
In the "files changed" view on GitHub you can view the PR commit-by-commit and comment on that commit's change
Most developers haven’t seemed to use another workflow unfortunately—& they scoff at suggesting the only workflow they know could be wrong.
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.
Before everyone jumps on CodeBerg, please remember it runs on donations! It doesn't have Micro$lop money behind. Please donate to projects like this :)
I remember recent discussions on the somewhat rudimentary physical server infrastructure. I would be a bit scared for a serious large project
https://news.ycombinator.com/item?id=46132901
This can have pros and cons. They will get much more vcpu / dollar on bare metal. And they can develop great operational discipline if they do it right.
On the downside, I don’t see them yet taking ops seriously. They are getting a lot of attention, but not yet establishing SLAs (at least not publicly). And their donations don’t seem to be scaling to the continued and expected demand.
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...
So it begins.....
Steam proved gaming doesn't depend on Windows, Linux can do it too.
Countries in Europe feed-up with Windows moving to Linux
LibreOffice is eating Microsoft 365 lunch
Microsoft buying GitHub caused a mass-exodus, its AI push is causing another mass-exodus.
Big open-source project moving away from GitHub, we only need a big player to make the move, followers will come.
> LibreOffice is eating Microsoft 365 lunch
No way.
I love LibreOffice. It's fantastic. I rolled it out to a prior employer where everyone needed a word processor but we certainly didn't need to pay Office prices when we didn't have requirements that only Office could satisfy. A high point was when we were having trouble collaborating on a DOCX file with a customer, then they sheepishly told us that they weren't using Office, but this other LibreOffice (OO.org at the time) thing. We laughed and told them we were, too. That day we started swapping ODT files instead and everything worked 100x better.
And all that said, I haven't seen LibreOffice in person in years. Mac shops uses Pages & friends for internal stuff, but really, almost everyone not using Office 365 or whatever they're calling it now is using Google Docs. Google is eating Microsoft's lunch in this space, and my gut estimate is that they split 95+% of the office software market between them.
I do wish that weren't the case, but my personal experience tells me it is. I wish it were more common, and also that there was a virtuous cycle where more Mac users made it get more attention, and more attention made it feel more like a "Mac-assed Mac app", and feeling more like a Mac-assed Mac app got it more users, etc. I just don't see that playing out.
Countries in Europe realized that if USA sanctions International Criminal Court judge - that judge suddenly loses access to their email/calendar/docs/etc because Microsoft/Google/etc have to comply.
For the rest - yes.
> LibreOffice is eating Microsoft 365 lunch
This one misses the point entirely, I'm sorry to say. Microsoft 365's "lunch" is that a majority of US businesses, schools, and governments are reliant on 365 for anything in their organization to function.
And also majority of European businesses and governments and schools. Europe is well integrated into US. Quite a few STOXX 600 have US wings or acquired US companies.
Basically a substantial (non-software) enginerring or financial work is done in Microsoft's proprietary formats, occasionaly involving VBA.
Many businesses cannot even pay salaries without macro-ridden Excel documents.
With 365 Microsoft has even stronger moat: cloud integrated co-editing using desktop apps. No browser will exceed C++/C# Office apps running directly on the PC. Not even proprietary apps have equivalent experience.
On top of that add all Azure, SharePoint etc. All big companies without exception use those and put significant portion of their business knowledge on Microsoft platforms.
US can literally kill Europe by just forcing Microsoft to shutdown its operations. It is fucking scary.
There are more effective ways of doing that. For example invalidate all european Visa and Mastercards. That would really kill most of Europe.
That one made me lol. This same conversation happened a little while ago.
Both powerpoint and excel are well ahead of the competition.
Copilot is also eating office, at least branding wise. :)
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.
Starting a migration is a lot easier than completing one.
> 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>
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.
More power to them. But donations can’t possibly scale to the demand. They are already having significant capacity issues as evidenced to response time spikes throughout the week.
It’s a great hobby app, and the forgejo software seems well assembled, but Codeberg needs to be a bit more forthcoming about their capacity before more large projects move over.
I want to see larger projects like Gentoo migrate, but everything will come grinding to a halt if codeberg doesn’t come up with scalable resourcing (money & capacity)
> More power to them. But donations can’t possibly scale to the demand.
In my opinion, for a Git forge, switching to any other main source of income would almost certainly lead to some form of enshitification
they have a lot of options for sales. they can sell their service and run a not-for-profit enterprise.
surviving on online donations is extremely rare. In their case, they are not getting that many impressions, so $1-$5 donations won't cover their expenses. Think of how expensive even a single customer like Gentoo would be if they fully migrated -- how many Gentoo contributors would have to contribute money to cover Gentoo hosting.
I'm sure they have a sales pipeline planned, and similar to Facebook, they don't want to kill the buzz with sales before they build their audience.
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.
> Their CI doesn't run a full pkgcheck I guess
I stand corrected (thanks Sam): This was previously the case before they made the announcement, it’s fully working now. Feel free to contribute on Codeberg.
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')
The unified search (org wide, across issues/prs/code) and custom search backend works really well.
Honestly I don't understand all the GitHub hate recently. Honestly seems like a fashionable trend. Virtue signaling.
There was a decade where they barely innovated. Maybe people forgot about that? Or maybe they are too young to remember? I'll gladly take all the advances over the past 8-ish years for the odd issue they have. GH actions has evolved A LOT and I'm a heavy Copilot user at the org/enterprise level..
The raft of outages lately (my company was disrupted by I think four last week?) have certainly (and deservedly) created some pent-up frustration. I'm personally frustrated with its poor performance on Safari.
Overall, though, it's ... fine. That's all. A little worse than it used to be, which is frustrating, but certainly nowhere near unusable. I stood up my own forge and mirror some repos to it. The performance is almost comically better. I know it's not a fair comparison: I have only one user. On the other hand, I'm on a 9-year-old Xeon located geographically farther from me than GitHub's servers.
I'm largely happy with GitHub though for public GitHub at least, search is now terrible - it doesn't seem to return anything when not logged in and if you are logged in the filtering options are limited (this was the case mid last year anyway - maybe it's improved but I've given up trying to use the web search).
Whatever the motivations are, at least the end result is moving to freer (non-proprietary) and sometimes self-hosted solutions. If virtue signaling is what it takes to get there, I would like more of it. Virtue signaling gave us quality universities and museums, after all...
Is that a unique feature to GitHub?
No, Gitlab has it too (don't know about the others offerings). Gitlab integrates Advanced Search via Elasticsearch, last I checked they had plans to make zoekt available as an alternative.
Thanks Gentoo! I've been forever happy that you are so committed to excellence even when it means being unique.
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.
codeberg is AMAZING and VERY VERY fast and snappy and EASY TO USE.
I REALLY recommend it
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.
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.
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.
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.
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.
Git was supposed to be "decentralized", but it never was.
This is completely untrue. Git is fully decentralized in the way it's designed. People use it in a centralized manner, but that has nothing to do with the tool itself.
If you familiarize yourself with the way people use it for Linux kernel development, you'll see that it doesn't have to be this way.
There is an entire ecosystem of products that have locked themselves (and their users) into Github for one reason or another. I hope a critical mass builds that forces them to open up to a wider range of alternatives.
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 a move off Github, though Codeberg has poor service availability.
I am also moving my "important for me" projects to Codeberg.
mmh, maybe the perfect time to leave github aswell and return to gentoo.
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 find GitLab and GitHub to be very similarly bad-to-barely-acceptable.
I used to be a GH fanboi. Why not - very convenient ... errm and that's it.
I now run a local Gitea. Its rather more performant and uptime is rather better too!
I have no idea why on earth I even considered using GH in the first place. Laziness I suppose.
Anyone with a brain can see that Github will have to be enshittified at scale with the pressure created from AI Code and everything generation. These guys are just getting ahead of the curve
Forgejo is so nice, been hosting it locally for my projects for a year or so
What we reallt need is a place for secure hosting, one where AI is gatekept. Right now the big AI companies just steal code and no one does anything about it. Its pure theft. A blatant violation of copyright.
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.
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.
"you need some serious infrastructure investment"
Well we could imagine where users give part of their laptop to join a pool of workers for builds.
If there are 3 builds that achieve the same output, one of it "wins" and is choosen.
Maybe we need a display that just shows each user approximately what they cost.
Not a wikipedia banner. No guilt verbiage. No unrelatable total site/year numbers like "2.6M out of 5M goal" etc.
Just like some little bit of ui in a corner somewhere that passively just sits there and shows it's state like a red/yellow/green light or a battery meter or something. And what it shows is some at-a-glance representation of what you are costing the service, positive or negative.
If the org is open and low profit or even non profit, or even reasonable profit but organized as a co-op, this can be a totally honest number, which will probably be suprisingly small.
(and if any full-profit type services don't like having that kind of info made quite so public because it makes it hard to explain their own prices, well golly that sure sounds awful)
This will obviously have no effect on some people.
But I know that something like that will absolutely eat at some people until they decide they will feel better if they make that dot turn green.
And everyone else who just wants to take something for free and doesn't like being reminded of it, has no basis for complaining or claiming to be outraged at being nagged or browbeaten. It's a totally passive out of the way bit of display making no demands at all and not even hindering or speedbumping anything.
Even when you click on it for more info and the links to how to donate etc, the verbiage is careful not to make kids or drive-by laypeople or anyone else without real means feel bad or feel obligated. We don't need your soup money, don't sweat it.
Maybe even include some stories about how we all wound up in our high paying IT jobs because of the availability of stuff other people wrote and let us use for free when we were kids or former truck drivers etc, and so that's how you can understand and believe we really are ok with you now using this for free.
Can't possibly get any lighter touch than that.
And yet the fact that the little thing is just there all the time in view, that alone will make it like a voluntary itch that if you know you can afford it, you should make that light green. It's like a totally wholesome use of gamification psychology.
I guess it will also have to somehow show not just what you cost yourself, but also what all the non-paying users are costing and what your fraction of that would be to cover those. At least some payers would need to pay significantly more than what they cost.
But I'd be real curious to see just how bad that skew is after a while if a lot of individuals do end up paying at least for themselves, where today most of them pay nothing.
That may make the need for whales much reduced and really no whales, just a bunch that only pay like twice what they cost. Or even less, a heavy user that costs more might be able to totally cover the entire cost of 10 other light users with only 10% more than their own cost. It could eventually smooth out to being no real burden at all even for the biggest payers.
That's getting to be a bit much info to display all in a single colored dot or something without text or some complicated graphic, but I think this much could be shown and still be simple and elegant. Even a simple dot can have several dimensions all at once. size, hue, saturation, brightness, let alone any more detail like an outline or more complex shape.
About the only thing I can see that is a bad thing is I bet this is a recipe for unfairly taxing women more than men. You just know that far more women will make that light green even if it's not easy, and far more men will happily let it ride forever even though they could afford it effortlessly, just to spend that $3 on a half of a coffee instead.
Glad to see more projects migrating off GitHub. GitHub needs to be abandoned. We can do without MS's EEE and fuck ups.
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.