Comment by JoshTriplett

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

38 comments

JoshTriplett

Reply
holysoles  10 days ago

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  10 days ago

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

  • rapnie  9 days 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.

bsimpson  10 days 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  9 days 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  8 days 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  9 days 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  9 days 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.

      3 replies →

rtpg  9 days 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  9 days ago

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

    • xigoi  9 days ago

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

      1 reply →

    • mbreese  9 days ago

      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.

angus-g  9 days 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...

pocksuppet  10 days ago

So... git's original design

  • JoshTriplett  9 days 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  9 days 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.

      13 replies →