Git isn't Distributed Enough

05/02 · ← Back · english · git · distribution · unix


There’s a certain saddness that comes from calling out into a deep pit, and another that comes from yelling at your pale-yellow wall. Both are essentially what it amounts to when you self-host a Git server today.

If you’re using the generic combination of cgit + gitolite, you’re in business. On paper, you should be able to share you work with anyone in the world— they can even help, if they want!

From the perspective of a would-be contributor, the work-flow is pretty simple, hypothetically. They fetch the source-code from your git server, tool around a bit, make patches, then e-mail them to you. Bing, bang, boom. No problem.

right?

According to Drew Devault, that’s exactly how “a large minority of the git community [collaborates].” But what minority is that, exactly? It certainly isn’t the minority that matters: the people who’ll be coding when we’re all dead and gone. Instead, that “large minority” is made up of the folks who are stuck in the past. They cling to the terminal, they cling to the shell, they cling to the workflow of the late 90s. Don’t get me wrong, I’m not saying they’re incorrect per se— it’s just that their culture and workflow is clearly growing more and more obsolete.

The majority of people are growing up on GitHub. To them, Git doesn’t look like e-mails and commands. It looks like buttons, accounts, avatars, stars, and IDE integrations. Interaction and collaboration are mere button-clicks away in their web-browser. In other words, now “Git” doesn’t actually mean git itself. It means the front-end and the eco-system around it.

Drew’s completely right— “git is already federated and decentralized.” But he’s also wrong.

Drew makes a great point, however, in showing that these two very different workflows aren’t entirely incompatible: That front-ends should use e-mail for communcated contributions for the user, between Git servers/users— which both keeps the illusion of a cushy, GitHub-esque experience, while also allowing the logistical advantages of using e-mail.

If you look at Git-server intercommunication as mainly being a question of how to share commits, then that’s a perfectly fair answer.

But commits aren’t the only thing that GitHub-like frontends offer. They offer bug-tracking, task-management, simple wiki-editing, user profiles, direct messages, etc, etc.

In other words, things that ActivityPub is perfectly suited for.

E-mail might be perfectly suited for simply patch and commit-sharing— the minimum for collaboration— but it doesn’t come close to meeting the expectations people have nowadays for “Git”.

A common example of ActivityPub’s obvious utility goes something like this: “Why shouldn’t someone be able to comment on one blog-post, when they’re on a different blog-host?”

Likewise, “Why shouldn’t someone be able to file a bug on one Git-repo, when they’re on a different Git-host?”

E-mail can take us pretty far— but it can’t go the whole nine yards.

For Git federation that can meet our standards, we need ActivityPub.