5 ms·

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
      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.
- Twisell 8mo ago
  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/ https://forgejo.org/docs/latest/user/agit-support/
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.

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
    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.
Twisell 8mo ago
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/ https://forgejo.org/docs/latest/user/agit-support/

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.