3 ms·

I really wish a cross site standard emerged to enable PRs from one forge to the next without creating accounts: - clone repo from original forge, push on yours

by lloeki 3y ago

I really wish a cross site standard emerged to enable PRs from one forge to the next without creating accounts: - clone repo from original forge, push on yours - open PR on your forge, kicking in a like-blog-trackbacks-of-yore API so that the PR would be known/opened on the original forge. The thing would really put the "Pull Request" back in PR. Lots of things to define and handle correctly to prevent abuse but it could be a much better distributed experience. I guess big players like GitHub would nit like that too much though as it would fragment their coding social network.

erlend_sh 3y ago
That’s what ActivityPub in GitLab and elsewhere aims to enable: https://gitlab.com/groups/gitlab-org/-/epics/11247 https://gitlab.com/groups/gitlab-org/-/epics/11247
- lloeki 3y ago
  Going through that link... that sounds great, thanks! In the discussion I also read about ForgeFed[0], also ActivityPub based, and which Forego is apparently implementing[1]. [0]: https://forgefed.org https://forgefed.org [1]: https://codeberg.org/forgejo/forgejo/issues/59 https://codeberg.org/forgejo/forgejo/issues/59
cxr 3y ago
The PR workflow is already overkill for about 90% of contributors and not what Git was designed for, anyway, so you can just ditch it. You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed.
- lloeki 3y ago
  > The PR workflow is [...] not what Git was designed for I would agree... in its GitHub incarnation. > You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed. Which is... where? The PR+fork model is what that implements: fork for the always-on storage so that upstream can fetch from it, PR for upstream to be notified about, discuss around, follow subsequent updates of, and track integration of the changeset. The problem in the GitHub model is that it's all happening on a single centralised platform, removing the distributed benefits of Git at great benefit to GitHub through network effects, stifling competition. What I propose is that the always-on storage need not be at GitHub, and there'd be a notification system towards GitHub to point to that always-on storage. Could be a bare GitHub repo with GitWeb (which is something one has to set up) + a curl to an upstream API endpoint, but sooner or later people are going to want to have a bit more than that, so having a forge do that (either a self-hosted one like Gitea/Forgejo or any hosted one like SourceHut/Codeberg/GitLab/Bitbucket) is practical. This essentially makes forges interoperable, restoring the distributed nature of git development that GitHub killed by centralising git hosting. (Of course you can s/GitHub/whatever-derivative/g above, I just focused on GitHub for the sake of simplicity because it's the monopolistic elephant in the room)
  - cxr 3y ago
    > Which is... where? The PR+fork model is what that implements We agree that GitHub's fork+PR workflow gives you the functional equivalent. But it is sufficient, not necessary. If you're working on a 600 MB repo and want to submit changes comprising 100 lines of additions and deletions as a first-time (and possibly one-time) contributor, forcing you to coordinate an additional always-on third copy of that repo is, as I said, total overkill for your ~5KB of changes—and that's before we even address that this is something that's required from every contributor. > I would agree... in its GitHub incarnation No, you're missing the point. Git wasn't even designed for Github-style pull requests (no matter where they're hosted). That's why Git doesn't actually have them. Only GitHub does (and everyone who decided to copy them). It's not just the fact that everyone centralizes around a single site that's the problem. It's that fork+PR for every single change from every single contributor is fundamentally the wrong model to begin with. "Pull requests" are for frequent collaborators, like the core development team on a given project: they all have each other's repos in their remotes for pushing and pulling to/from whomever they're working with on a given thing when they're working together. Non-core contributors shouldn't even be worrying about the question of "where" to host things—they don't need to host things—who'd want to pull from them, and why? (And why burden them with provisioning hundreds of megabytes—or, in aggregate, gigabytes—of always-on online storage? Again: complete overkill.)

by lloeki 3y ago

erlend_sh 3y ago

That’s what ActivityPub in GitLab and elsewhere aims to enable: https://gitlab.com/groups/gitlab-org/-/epics/11247 https://gitlab.com/groups/gitlab-org/-/epics/11247

lloeki 3y ago
Going through that link... that sounds great, thanks! In the discussion I also read about ForgeFed[0], also ActivityPub based, and which Forego is apparently implementing[1]. [0]: https://forgefed.org https://forgefed.org [1]: https://codeberg.org/forgejo/forgejo/issues/59 https://codeberg.org/forgejo/forgejo/issues/59

cxr 3y ago

The PR workflow is already overkill for about 90% of contributors and not what Git was designed for, anyway, so you can just ditch it. You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed.

lloeki 3y ago
> The PR workflow is [...] not what Git was designed for I would agree... in its GitHub incarnation. > You have the repo on your machine, and you have a public upstream. You don't need an third copy on your own server, too—you just need a place to publish what you actually changed. Which is... where? The PR+fork model is what that implements: fork for the always-on storage so that upstream can fetch from it, PR for upstream to be notified about, discuss around, follow subsequent updates of, and track integration of the changeset. The problem in the GitHub model is that it's all happening on a single centralised platform, removing the distributed benefits of Git at great benefit to GitHub through network effects, stifling competition. What I propose is that the always-on storage need not be at GitHub, and there'd be a notification system towards GitHub to point to that always-on storage. Could be a bare GitHub repo with GitWeb (which is something one has to set up) + a curl to an upstream API endpoint, but sooner or later people are going to want to have a bit more than that, so having a forge do that (either a self-hosted one like Gitea/Forgejo or any hosted one like SourceHut/Codeberg/GitLab/Bitbucket) is practical. This essentially makes forges interoperable, restoring the distributed nature of git development that GitHub killed by centralising git hosting. (Of course you can s/GitHub/whatever-derivative/g above, I just focused on GitHub for the sake of simplicity because it's the monopolistic elephant in the room)
- cxr 3y ago
  > Which is... where? The PR+fork model is what that implements We agree that GitHub's fork+PR workflow gives you the functional equivalent. But it is sufficient, not necessary. If you're working on a 600 MB repo and want to submit changes comprising 100 lines of additions and deletions as a first-time (and possibly one-time) contributor, forcing you to coordinate an additional always-on third copy of that repo is, as I said, total overkill for your ~5KB of changes—and that's before we even address that this is something that's required from every contributor. > I would agree... in its GitHub incarnation No, you're missing the point. Git wasn't even designed for Github-style pull requests (no matter where they're hosted). That's why Git doesn't actually have them. Only GitHub does (and everyone who decided to copy them). It's not just the fact that everyone centralizes around a single site that's the problem. It's that fork+PR for every single change from every single contributor is fundamentally the wrong model to begin with. "Pull requests" are for frequent collaborators, like the core development team on a given project: they all have each other's repos in their remotes for pushing and pulling to/from whomever they're working with on a given thing when they're working together. Non-core contributors shouldn't even be worrying about the question of "where" to host things—they don't need to host things—who'd want to pull from them, and why? (And why burden them with provisioning hundreds of megabytes—or, in aggregate, gigabytes—of always-on online storage? Again: complete overkill.)