Federated Git

Published on 17 December, 2019
Tags: thoughts

Git is a Distributed Version Control System or DVCS, created for the Linux Kernel project. The idea behind a DVCS is that there is no concept of central repository. Every copy (clone) has all the information. But generally, there is a central repository that acts as a single source of truth for all the developers. Git hosting services (like Github, Gitlab, Bitbucket) hosts the central repository for a project. Over the years, the git hosting services have build workflows around Git, such as Pull Request. However, such workflows are generally proprietary and only works on that platform. It means a user needs to be part of the platform (as a user) to use the workflow.

There are open-source alternatives to proprietary Git hosting platforms (like Gitea, Gogs, Gitlab). But, it is not easy for someone to switch entirely to these alternatives because of the builtin workflows. In my opinion, this defeats the purpose of a DVCS like Git. The Linux Kernel project uses mailing lists to send patches. This process keeps the distributed nature of Git alive.

One idea is to leverage the ActivityPub protocol to solve the inter hosting collaboration problem. As long as two platforms implement this protocol, the pull requests or patch submission process can use it to communicate between instances. This way, a user from instance A will be able to submit changes to a project on instance B without ever needing to register on instance B.

The question is, will the proprietary Git hosting providers implement such a system? It allows people to collaborate without ever being part of the instance.

P.S.: After some searching, I came up with a similar solution called Forgefed. There is also an effort by someone to make email collaboration trivial and accessible to the users. The project is called SourceHut.

Update: Fixed the link of SourceHut.