[vorpalhex]

There was an attempt to bring a distributed forge architecture to gitea and co. The idea being the project could be hosted on one instance but you could fork to your own to do your work before PRing back to the project.

Github but bring your own.

I believe the project died out but it was a good idea. All the benefits of Github without the lock in and single point of failure.

[imiric]

Git already has a distributed workflow for submitting patches: email[1].

Ultimately a "pull request" is just that; a request for someone to pull your branch into theirs. You can already add Git remotes from different services, review the changes locally, and collaborate over email. GitHub et al simply add a nicer UI for this, but there's no reason why you couldn't make a PR from one service to another. If only they'd be willing to interoperate, which is the biggest hurdle.

I'm not familiar with why that Gitea project failed, but I imagine that making this work for multiple instances of a single OSS project would be much easier.

[1]: https://www.git-scm.com/book/en/v2/Distributed-Git-Contribut...

[stavros]

Yeah, that would have been really good... Too bad it doesn't seem to have come to nothing.

[ratmice]

It looks like gitea supports running a proc_receive hook which can be used to implement pull requests over git:// using a client like https://git-repo.info/en/

(full disclosure) I had written a proof of concept implementation that allows you to use the git-repo.info client to send PRs over git protocol, which you can find here https://github.com/pullreqr/pullreqr_githook

The primary impediment seems partially to be social/coordination where distributed git requires clients to be set up apriori, but it does work in cases where you are using it in house, etc.

I'd kind of be happy to spend more time on it, but with no one actually running the protocol publicly, there is no one to send/receive PRs to or from.

[paradox460]

Basically fossil?