8 ms·

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 develop

• JoshTriplett 8mo ago
  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 8mo ago
    For those curious, the federation roadmap is here: https://codeberg.org/forgejo-contrib/federation/src/branch/main/FederationRoadmap.md 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 https://github.com/PatNei/GITHUB2FORGEJO Note that Forgejo's API has a bug right now and you need to manually re-configure the mirror credentials for the mirrors to continue to receive updates.
  • bsimpson 8mo ago
    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 8mo ago
      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.
      • viraptor 8mo ago
        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)
    • debugnik 8mo ago
      > 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?
      • bsimpson 8mo ago
        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.
        • techcode 8mo ago
          Perhaps I'm missing something... If your commits are not all independent - I don't see how could they ever be pulled/merged independently?
          • JoshTriplett 8mo ago
            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.
        • mbreese 8mo ago
  • mikepurvis 8mo ago
    GitLab has been talking about federation at least between instances of itself for 8+ years: https://gitlab.com/groups/gitlab-org/-/epics/16514 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).
    • rapnie 8mo ago
      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.
  • okanat 8mo ago
    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 https://github.com/git-bug/git-bug
  • pocksuppet 8mo ago
    So... git's original design
    • JoshTriplett 8mo ago
      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.
      • shakna 8mo ago
        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 8mo ago
          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- 8mo ago
            `git send-email` and `git am` are built into Git, not additional tools.
            • JoshTriplett 8mo ago
              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.
  • rtpg 8mo ago
    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!
    • jamesfinlayson 8mo ago
      Agreed. I assume there are reasons for this design choice though?
      • xigoi 8mo ago
        Presumably, the reasons are that it inflates the number of repositories, which is useful when showing numbers to investors.
        • cxr 8mo ago
          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.
  • angus-g 8mo ago
    That's kind of the way Tangled works, right? Although it's Yet Another Platform so it's still a little bit locked in...
  • Duplicake 8mo ago
    Have you seen https://tangled.org/ https://tangled.org/
  • LtWorf 8mo ago
    Microsoft won't have it.
• VorpalWay 8mo ago
  Arch Linux have used their own gitlab instance for a long time (though with mirrors to GitHub). Debian and Fedora have both run their own infra for git for a long time. Not sure about other distros. I was surprised Gentoo used GitHub at all. Pretty sure several of these distros started doing this with cvs or svn way back before git became popular even.
  • Foxboron 8mo ago
    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.archlinux.org/ https://web.archive.org/web/20070512063341/http://projects.a...
    • mburns 8mo ago
      Gitlab started in 2011. Which, granted, is still after 2007. https://www.ycombinator.com/companies/gitlab https://www.ycombinator.com/companies/gitlab
    • kunley 8mo ago
      Many companies were using commercially licensed Gitlab in 2017 already, so it must have been established before that time. Definitely not in 2019
  • Pay08 8mo ago
    Both GitHub and now Codeberg are mirrors of a self-hosted cgit repository of Gentoo.
• encom 8mo ago
  >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.
  • wongarsu 8mo ago
    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
• toastal 8mo ago
  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 https://codeberg.org/toastal/github-less-social>.
• tiffanyh 8mo ago
  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 https://haskellforall.com/2026/02/browse-code-by-meaning [2] [0] https://x.com/mitchellh/status/2023502586440282256#m https://x.com/mitchellh/status/2023502586440282256#m [1] https://x.com/mitchellh/status/2023499685764456455#m https://x.com/mitchellh/status/2023499685764456455#m [2] https://x.com/mitchellh/status/2023497187288907916#m https://x.com/mitchellh/status/2023497187288907916#m
  • blibble 8mo ago
    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)
    • mbreese 8mo ago
      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)
  • Starlevel004 8mo ago
    Person who pays for AI: We should make everything revolve around the thing I pay for
    • 8mo ago
• jruz 8mo ago
  I would say started with Zig. For us Europeans has more to do with being local that reliability or copilot.
• shevy-java 8mo ago
  I hope so. Ever since Trump and the US corporations declared software-war against Europeans, I want to reduce all dependencies on US corporations as much as possible. Ideally to zero. Also hardware-wise. This will take a long time, but Canadians understood the problem domain here. European politicians still need to understand that Trump and his cronies changed things permanently.
• kpcyrd 8mo ago
  I moved one of my projects from Github to codeberg because Github can't deal with sha256 repositories, but codeberg can.
  • surfaceofthesun 8mo ago
    What's the benefit of using sha256 for a repository?
    • kpcyrd 8mo ago
      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.
• shmerl 8mo ago
  It's been going on for a while. Recent AI craze just accelerates it.
  • onli 8mo ago
    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.
• sathish316 8mo ago
  It might also be a reflection of the number of frequent outages of GitHub under Microsoft recently and GitHub Copilot push
• Brian_K_White 8mo ago
  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.
• ori_b 8mo ago
  No, the start was a lot time ago.
• matltc 8mo ago
  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