The one feature I really crave to see on git forges is the ability to create a PR/MR without forking the project locally on that instance (the target instance). It would be nice to not need an account on the target instance at all, but the important need is to create a PR/MR without forking there. It should be simple to do this: someone with an account could just send a .patch file in git format-patch format. I regret that the design chosen makes that feature basically the very last things, after things nobody cares about (follow projects on other instances, big meh).
Note: the problem with forking a project is that it consumes resources on the server. If you make forking avoidable for graceful interaction, you can let people create accounts with limited rights, and not worry too much about their resource consumption.
If you let people fork on your server, you can do copy-on-write optimizations at the time of the fork, but obviously you also need to let them push new content to your server, and basically you are acting like a data-storage service for them. It is then very difficult to distinguish between malicious usage of your storage resources and expected usage. For example, if the original repository has large-ish binary blobs stored in them, reasonable commits pushed to the new fork may contain many new versions of those large binary blobs.
Oh, I see. So you’re basically worried about abusive users using repos as object storage? So the problem isn’t really forks, it’s allowing repo creation at all (but if you disable that, now suddenly nobody can send MRs because they can’t fork)?
Yes. This is a concrete problem for me because some instance operators disable repo creation for non-trusted accounts for this reason, breaking the expected interaction patterns for contributions from non-trusted users.
That’s really interesting to know, thanks. I had assumed for some reason that it was making a deep copy.
For me then, it’s a small cognitive load to fork. I now have this copy of the project under my account, that maybe receives a commit or two and then is usually abandoned. I can delete it to clean up the clutter, but what if I get on a role and contribute again soon? I refork and do the whole dance again.
Yes, and a service that would accept such patches (for example the git format-patch format that makes it easy and convenient to send a series of commits with commit messages, etc.) through a standard web API, for example a POST request, could easily be connected with another server/instance that would submit PRs/MRs on their user’s behalf using this mechanism. I work on my favorite gitlab instance, I can use it to “send a MR” to another instance: my instance computes this patch file (trivial), sends the POST request on my behalf (I provided my username on the target instance in a form field), and I get a login screen to authenticate my account on the receiving instance that then creates the MR.
This is easy to do with very simple and standard web interaction patterns, open to either manual or automated use.
I’m keeping my expectations tempered atm, since Gitlab isn’t implementing this, an external contributor is. That’s still good, but as always with an external contributor contributing code to corp open source, there’s the risk that company priorities aren’t aligned, or shift such that the contribution is no longer welcomed.
Anything that gets us back in the direction of distributed and decentralized version control is welcome. With ActivityPub, hopefully this means you can use your account from another service altogether (not limited to creating a account with GitLab account somewhere else but using a Mastodon account for instance).
The one feature I really crave to see on git forges is the ability to create a PR/MR without forking the project locally on that instance (the target instance). It would be nice to not need an account on the target instance at all, but the important need is to create a PR/MR without forking there. It should be simple to do this: someone with an account could just send a
.patchfile ingit format-patchformat. I regret that the design chosen makes that feature basically the very last things, after things nobody cares about (follow projects on other instances, big meh).Note: the problem with forking a project is that it consumes resources on the server. If you make forking avoidable for graceful interaction, you can let people create accounts with limited rights, and not worry too much about their resource consumption.
What resources? Not disk space (at least on GitHub): https://github.blog/2015-09-22-counting-objects/#your-very-own-fork-of-rails
If you let people fork on your server, you can do copy-on-write optimizations at the time of the fork, but obviously you also need to let them push new content to your server, and basically you are acting like a data-storage service for them. It is then very difficult to distinguish between malicious usage of your storage resources and expected usage. For example, if the original repository has large-ish binary blobs stored in them, reasonable commits pushed to the new fork may contain many new versions of those large binary blobs.
Oh, I see. So you’re basically worried about abusive users using repos as object storage? So the problem isn’t really forks, it’s allowing repo creation at all (but if you disable that, now suddenly nobody can send MRs because they can’t fork)?
Yes. This is a concrete problem for me because some instance operators disable repo creation for non-trusted accounts for this reason, breaking the expected interaction patterns for contributions from non-trusted users.
That’s really interesting to know, thanks. I had assumed for some reason that it was making a deep copy.
For me then, it’s a small cognitive load to fork. I now have this copy of the project under my account, that maybe receives a commit or two and then is usually abandoned. I can delete it to clean up the clutter, but what if I get on a role and contribute again soon? I refork and do the whole dance again.
I’d be nice to avoid all that and send a patch.
This is the big problem. PRs are not part of git but have become integral because of its UX.
There really isn’t a good solution here: either send patches via email or via “side” proprietary APIs.
Git appraise looks interesting but outside collaboration is not possible.
I could see an activity pub implementation of PR be interesting, but you still need an account somewhere just to send a patch.
It would be awesome to be able to just copy/paste a diff or patch.
Yes, and a service that would accept such patches (for example the
git format-patchformat that makes it easy and convenient to send a series of commits with commit messages, etc.) through a standard web API, for example a POST request, could easily be connected with another server/instance that would submit PRs/MRs on their user’s behalf using this mechanism. I work on my favorite gitlab instance, I can use it to “send a MR” to another instance: my instance computes this patch file (trivial), sends the POST request on my behalf (I provided my username on the target instance in a form field), and I get a login screen to authenticate my account on the receiving instance that then creates the MR. This is easy to do with very simple and standard web interaction patterns, open to either manual or automated use.100% want this.
Good to see that don’t ignore other work that ha been done in this area. They are aware of ForgeFed, only not using it for this stage yet: https://gitlab.com/groups/gitlab-org/-/epics/11247#note_1527749828
I’ll repost what I said about this on fedi here:
I’m keeping my expectations tempered atm, since Gitlab isn’t implementing this, an external contributor is. That’s still good, but as always with an external contributor contributing code to corp open source, there’s the risk that company priorities aren’t aligned, or shift such that the contribution is no longer welcomed.
I hope support for this comes to Gitea too soon, as a lot of people prefer Gitea to GitLab, as it is more similar to GitHub.
Yup, Gitea’s been working on it for a bit too https://github.com/go-gitea/gitea/issues/14186
Hey everyone running a GitLab instance. Congratulations on your new moderation team, whether you want one or not. You’ll need it. :)
Unless, of course, one doesn’t, because they disabled federation, and just uses it the way they did before.
Do you know if it’s opt-in or opt-out?
I think this is a great step forward that I was looking forward to for a few years now! Yay!
Anything that gets us back in the direction of distributed and decentralized version control is welcome. With ActivityPub, hopefully this means you can use your account from another service altogether (not limited to creating a account with GitLab account somewhere else but using a Mastodon account for instance).