Is this the start of a more frequent code-migrations out of Github?
For years, the best argument for centralizing on Github was that this was where the developers were. This is where you can have pull requests managed quickly and easily between developers and teams that otherwise weren't related. Getting random PRs from the community had very little friction. Most of the other features were `git` specific (branches, merges, post-commit hooks, etc), but pull requests, code review, and CI actions were very much Github specific.
However, with more Copilot, et al getting pushed through Github (and now-reverted Action pricing changes), having so much code in one place might not be enough of a benefit anymore. There is nothing about Git repositories that inherently requires Github, so it will be interesting to see how Gentoo fares.
I don't know if it's a one-off or not. Gentoo has always been happy to do their own thing, so it might just be them, but it's a trend I'm hearing talked about more frequently.
I really like @mitchellh perspective on this topic of moving off GitHub.
---
> If you're a code forge competing with GitHub and you look anything like GitHub then you've already lost. GitHub was the best solution for 2010. [0]
> Using GitHub as an example but all forges are similar so not singling them out here This page is mostly useless. [1]
> The default source view ... should be something like this: https://haskellforall.com/2026/02/browse-code-by-meaning [2]
[0] https://x.com/mitchellh/status/2023502586440282256#m
[1] https://x.com/mitchellh/status/2023499685764456455#m
[2] https://x.com/mitchellh/status/2023497187288907916#m
Starlevel004
today at 9:06 PM
Person who pays for AI: We should make everything revolve around the thing I pay for
for [1] he's right for his specific use case
when he's working on his own project, obviously he never uses the about section or releases
but if you're exploring projects, you do
(though I agree for the tree view is bad for everyone)
I also check for the License of a project when I'm looking at a project for the first time. I usually only look at that information once, but it should be easily viewed.
I also look for releases if it's a program I want to install... much easier to download a processed artifact than pull the project and build it myself.
But, I think I'm coming around to the idea that we might need to rethink what the point of the repository is for outside users. There's a big difference in the needs of internal and external users, and perhaps it's time for some new ideas.
(I mean, it's been 18 years since Github was founded, we're due for a shakeup)
JoshTriplett
today at 6:35 PM
I'm really looking forward to some form of federated forking and federated pull requests, so that it doesn't matter as much where your repository is.
holysoles
today at 6:48 PM
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.
mikepurvis
today at 7:17 PM
GitLab has been talking about federation at least between instances of itself for 8+ years: https://gitlab.com/groups/gitlab-org/-/epics/16514
Once the protocols are in place, one hopes that other forges could participate as well, though the history of the internet is littered with instances where federation APIs just became spam firehoses (see especially pingback/trackback on blog platforms).
I use GitHub because that's where PRs go, but I've never liked their PR model. I much prefer the Phabricator/Gerrit ability to consider each commit independently (that is, have a personal branch 5 commits ahead of HEAD, and be able to send PRs for each without having them squashed).
I wonder if federation will also bring more diversity into the actual process. Maybe there will be hosts that let you use that Phabricator model.
I also wonder how this all gets paid for. Does it take pockets as deep as Microsoft's to keep npm/GitHub afloat? Will there be a free, open-source commons on other forges?
JoshTriplett
today at 8:32 PM
Personally, I'd like to go the other way: not just that PRs are the unit of contribution, but that rebased PRs are a first-class concept and versioning of the changes between entire PRs is a critical thing to track.
I would love git-bug project[1] to be successful in achieving that. That way Git forges are just nice Web porcelain on top of very easy to migrate data.
[1] https://github.com/git-bug/git-bug
pocksuppet
today at 7:23 PM
So... git's original design
JoshTriplett
today at 7:57 PM
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.
JoshTriplett
today at 8:35 PM
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.
greyface-
today at 9:55 PM
`git send-email` and `git am` are built into Git, not additional tools.
I would say started with Zig.
For us Europeans has more to do with being local that reliability or copilot.
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>.
shevy-java
today at 8:03 PM
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.
VorpalWay
today at 7:07 PM
Arch Linux have used their own gitlab instance for a long time (though with mirrors to GitHub). Debian and Fedora have both run their own infra for git for a long time. Not sure about other distros. I was surprised Gentoo used GitHub at all.
Pretty sure several of these distros started doing this with cvs or svn way back before git became popular even.
I moved one of my projects from Github to codeberg because Github can't deal with sha256 repositories, but codeberg can.
>code-migrations out of Github
I hope so. When Microsoft embraced GitHub there was a sizeable migration away from it. A lot of it went to Gitlab which, if I recall correctly, tanked due to the volume.
But it didn't stick. And it always irked me, having Microsoft in control of the "default" Git service, given their history of hostility towards Free software.