Gentoo on Codeberg

2026-02-1717:21436153www.gentoo.org

News and information from Gentoo Linux

Codeberg logo

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

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

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

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

Once you’re ready to create your PR:

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

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

More documentation can be found on our wiki.


Read the original article

Comments

  • By mbreese 2026-02-1718:2113 reply

    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.

    • By JoshTriplett 2026-02-1718:359 reply

      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.

      • By holysoles 2026-02-1718:48

        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.

      • By mikepurvis 2026-02-1719:171 reply

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

        • By rapnie 2026-02-1814:24

          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.

      • By bsimpson 2026-02-1719:093 reply

        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?

        • By Twisell 2026-02-186:09

          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/

        • By JoshTriplett 2026-02-1720:321 reply

          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.

          • By viraptor 2026-02-1911:40

            This is coming to GH soonish. Some clunky alpha version of this UI has been shared on the bad social site. (First class rebasing / stacked PRs)

        • By debugnik 2026-02-1722:501 reply

          > 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?

          • By bsimpson 2026-02-1723:082 reply

            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.

            • By mbreese 2026-02-1811:49

              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.

            • By techcode 2026-02-188:151 reply

              Perhaps I'm missing something... If your commits are not all independent - I don't see how could they ever be pulled/merged independently?

              • By JoshTriplett 2026-02-1822:25

                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.

      • By rtpg 2026-02-1723:232 reply

        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!

        • By kwk1 2026-02-185:26

          This is supported on Codeberg (and Forgejo instances in general) via the "AGit workflow", see https://forgejo.org/docs/latest/user/agit-support/

        • By jamesfinlayson 2026-02-182:102 reply

          Agreed. I assume there are reasons for this design choice though?

          • By xigoi 2026-02-1811:141 reply

            Presumably, the reasons are that it inflates the number of repositories, which is useful when showing numbers to investors.

            • By cxr 2026-02-1815:47

              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.

          • By mbreese 2026-02-1812:02

            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.

      • By okanat 2026-02-1719:22

        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

      • By angus-g 2026-02-183:53

        That's kind of the way Tangled works, right? Although it's Yet Another Platform so it's still a little bit locked in...

      • By pocksuppet 2026-02-1719:231 reply

        So... git's original design

        • By JoshTriplett 2026-02-1719:571 reply

          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.

          • By shakna 2026-02-1720:171 reply

            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.

            • By JoshTriplett 2026-02-1720:351 reply

              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.

              • By greyface- 2026-02-1721:551 reply

                `git send-email` and `git am` are built into Git, not additional tools.

                • By JoshTriplett 2026-02-1722:262 reply

                  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.

                  • By qdotme 2026-02-181:242 reply

                    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.

                    • By JoshTriplett 2026-02-181:393 reply

                      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.

                      • By qdotme 2026-02-1817:12

                        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.

                      • By abc123abc123 2026-02-1816:24

                        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.

                      • By stackghost 2026-02-184:48

                        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.

                  • By heliumtera 2026-02-1723:241 reply

                    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.

                    • By JoshTriplett 2026-02-1723:442 reply

                      Sorry to hear that you don't see the value in it. Many others do.

                      • By heliumtera 2026-02-180:14

                        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.

      • By Duplicake 2026-02-1815:09

        Have you seen https://tangled.org/

      • By LtWorf 2026-02-1922:52

        Microsoft won't have it.

    • By toastal 2026-02-1719:33

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

    • By VorpalWay 2026-02-1719:072 reply

      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.

    • By tiffanyh 2026-02-1719:549 reply

      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

      • By Starlevel004 2026-02-1721:061 reply

        Person who pays for AI: We should make everything revolve around the thing I pay for

        • By nine_k 2026-02-180:491 reply

          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.

          • By techcode 2026-02-188:39

            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.

      • By resonious 2026-02-182:12

        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.

      • By rtpg 2026-02-1723:22

        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.

      • By hparadiz 2026-02-181:05

        This looks like a confusing mess to me.

      • By blibble 2026-02-1720:231 reply

        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)

        • By mbreese 2026-02-1721:29

          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)

      • By crabmusket 2026-02-184:45

        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?

      • By Rapzid 2026-02-182:06

        Oh FFS. Twitter really brings out the worst in people. Prefer the more deeply insightful and measured blog posting persona.

      • By pojntfx 2026-02-180:03

        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.

    • By jruz 2026-02-1720:00

      I would say started with Zig.

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

    • By encom 2026-02-1719:181 reply

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

      • By wongarsu 2026-02-1812:39

        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

    • By kpcyrd 2026-02-1720:371 reply

      I moved one of my projects from Github to codeberg because Github can't deal with sha256 repositories, but codeberg can.

      • By surfaceofthesun 2026-02-2015:281 reply

        What's the benefit of using sha256 for a repository?

        • By kpcyrd 2026-02-2514:40

          Security, sha1 was deprecated in 2011 by NIST due to security concerns, and browsers reject sha1 certificates as invalid since 2017.

          Yet programmers in 2026 for some reason are still using it when signing their git tags and commits. Unless they are using a sha256 git repository.

    • By Brian_K_White 2026-02-184:51

      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.

    • By shevy-java 2026-02-1720:03

      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.

    • By shmerl 2026-02-182:331 reply

      It's been going on for a while. Recent AI craze just accelerates it.

      • By onli 2026-02-1812:42

        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.

    • By sathish316 2026-02-183:25

      It might also be a reflection of the number of frequent outages of GitHub under Microsoft recently and GitHub Copilot push

    • By ori_b 2026-02-1813:18

      No, the start was a lot time ago.

    • By matltc 2026-02-2121:08

      I get the sense that this is true for many enshittified services. See anything Microsoft. The FOSS movement seems to be gaining some traction again.

      My guess is it's driven by very poor user experience coupled with worse product.

      Technical leople who care about privacy/surveillance at least a little bit need take one look at the current state of tech and US govt to see how fucking fast dystopia is becoming reality. See discord/openai writeup that came out, ads literally everywhere, flock and ring cameras wide open and passively performing recon, routers doing the same... it's like snow crash out here

      Makes perfect sense that those who know would say fuck this, im out. Convenience isn't worth it anymore

  • By xvilka 2026-02-1718:456 reply

    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.

    • By bjackman 2026-02-1720:135 reply

      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.

      • By lima 2026-02-1813:50

        > 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/

      • By seabrookmx 2026-02-1722:561 reply

        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.

        • By bjackman 2026-02-187:431 reply

          You can't "stack" MRs in Gitlab though right? So if you're merging a complex feature you just have one huge mega commit?

          • By techcode 2026-02-188:551 reply

            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.

            • By bjackman 2026-02-1815:331 reply

              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.

              • By seabrookmx 2026-02-1816:25

                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.

      • By maccard 2026-02-180:59

        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

      • By jamesfinlayson 2026-02-183:52

        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.

      • By Intralexical 2026-02-1723:51

        What do people think of ReviewBoard?

    • By viraptor 2026-02-1720:32

      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.

    • By razighter777 2026-02-1721:091 reply

      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.

      • By IshKebab 2026-02-1722:232 reply

        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.

        • By klardotsh 2026-02-182:35

          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.

        • By SahAssar 2026-02-1723:50

          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)

    • By ahartmetz 2026-02-182:162 reply

      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.

      • By toastal 2026-02-188:22

        Most developers haven’t seemed to use another workflow unfortunately—& they scoff at suggesting the only workflow they know could be wrong.

      • By jamietanna 2026-02-1821:36

        In the "files changed" view on GitHub you can view the PR commit-by-commit and comment on that commit's change

    • By arccy 2026-02-1719:372 reply

      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.

      • By shimman 2026-02-1719:43

        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.

      • By bflesch 2026-02-1719:521 reply

        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.

        • By plorkyeran 2026-02-1720:03

          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.

    • By hulitu 2026-02-217:28

      > The performance degraded significantly from what was the experience from 10 years ago. UI became an absolute mess. Maybe even vibe-coded.

      Just like Microsoft Windows. I wonder if they are the same company. /s

  • By cbarrick 2026-02-1719:311 reply

    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.

HackerNews