Skip to main content


Federated code hosting

Are you interested in #federated #code hosting? This term means a site like #GitHub, #GitLab, #Cogs or #Gitea - but instead of all servers being an individual part of the #web, they talk to each other just like servers in the #fediverse. Imagine being able to open issues, make pull requests and engage in discussion, to any other repository from your own personal code hosting server?

Approxi... show more

Err… anything git powered (or mercurial) is “#federated” by definition.

You can already have mirrors with #GitLab (and probably with github too, but I don't know or care of that offer a self hosting option).

In other words, you either explained yourself very badly or, I suspect, you do not understand the technology.

There are many distinct things here. You are completely correct about git and other VCS's not being centralized, but that doesn't make them federated. A more correct term would be decentralized.

In the above post we are not talking about pure git or other VCS's. We're talking about platforms for code hosting that in the backend use one or more VCS's for storage of code. These platforms, like #GitHub, #GitLab etc, are much more than places where to store code. They have rich social functions that are closer to social media than VCS functionality. These include writing posts (issues), making merge requests, commenting on other peoples issues, merge requests and even single commits, likes and other emoji reactions, etc.

These are the functions that we need a federation protocol that allows these social interactions to happen cross-server, cross-platform, even cross-VCS. It's possible you don't need these functions, but the popularity of GitHub proves millions of developers do.

-Jason / Feneas

Let's call it "user-friendly federation" ;-)

`git format-patch` isn't as much as #GitHub PRs or #GitLab MRs.

What exactly is there that you can't do today via #GitLab webhooks?

@gittaca, joking aside, if you ever had to work on code from behind a slow, $10/minute #Inmarsat phone, you'd truly come to appreciate format-patch (and #git in general)! 🙂

Agreed :-) I used it once or twice, but always behind a DSL.

Still, GUI-approaches like taught in are _probably_ more effective in captur...ivating newcomers into the #FLOSS world.

Indeed! For the avoidance of doubt, I am a happy #GitLab user myself (OTOH I could never stand #Github). It's just that I fail to see what possible benefit what the OP is proposing could have. I can already self-host #GitLab instances, #git is distributed by design, and working on issues, #email complements the web interface (and clients such as #LabCoat) very nicely. Purely out of curiosity I did some experimenting some years ago with using webhooks + API + - 1/3

@feneas some simple #NodeJS glue to replicate an issue tracker and it worked really nicely (along with pipeline notifications via #XMPP, which I was very fond of). I didn't try, but it should be possible to bridge GitLab and github projects this way too. Seems like someone is trying to reinvent the wheel to solve a non-problem here. Then again, maybe I just fail to grasp the idea. - 2/3

- 3/3

Cross-server MRs for everyone, not just for those who know how to _implement_ what's possible ;-)

GitLab itself is discussing this in

Exactly, so why try to reinvent the wheel? @feneas could just distribute a #GitLab image with the relevant webhooks preloaded. Or just wait until that GitLab issue gets implemented. 🙂

Many thanks for digging out that ticket, I wasn't aware of it and it sounds rather exciting. 👍

You're welcome :-) I think there is definitely space for 3 types of wheels. 7 would get ridiculous.

Yeah !
That will mean real forks, real pull requests, credentials maintained by a trusted server.
Why not the ability to post a blog post about our project in plume, screenshot in pixel and screencast on peertube.
If we have tasks / bug trackers in federation, that may even be amazing.