[xg15]

I mean, at least git is easily "re-decentralizable" if you have to: Just add another remote to your working copy and push your state.

I also believe there are lots of companies who run their own internal git services to not be dependent on GitHub.

I agree though, in theory, git would allow some fully p2p working mode, where each developer just adds the machines of the other developers as remotes and there is no "authoritative" remote at all. If that was ever seriously proposed as a real working mode, it definitely didn't catch on, due to it quickly becoming extremely confusing.

In practice, having one universally agreed upon "authoritative" location of the project repo gives you an enormous amount of advantages, more than a p2p setup would give you.

I think as long as you can freely choose where to host that authoritative version and can quickly change its location if need be, I'd still consider git to be decentralised in practice.

[tsimionescu]

> I also believe there are lots of companies who run their own internal git services to not be dependent on GitHub.

The same is true of Subversion or CVS or Perforce, which are all very centralized source control systems. Relying on Github.com itself is another level of centralization over and above the near-universal industry pattern of having a centralized repo.

> I agree though, in theory, git would allow some fully p2p working mode, where each developer just adds the machines of the other developers as remotes and there is no "authoritative" remote at all. If that was ever seriously proposed as a real working mode, it definitely didn't catch on, due to it quickly becoming extremely confusing.

That is more or less how Linux kernel development works, with Linus' own repo just being more respected than others, but with many entities maintaining their own central repos (e.g. many distros and larger organizations only manually take patches or merges from Linus' repo, they don't otherwise rely on it in their automation). Changes are often collaboratively worked on for months or even years outside in sine of these repos before being sent to one of the official maintainers for inclusion in Linus' repo.

Now, this practice makes no sense at all for a centralized entity like a company, which is why virtually all companies used centralized repos where all code and collaboration happens by mandate - whether using Hg, Git, or SVN.

[xg15]

> but with many entities maintaining their own central repos

This sounds more "federated" than p2p though. I imagine each organisation has again a centralized hub for coordinating their own development on the kernel. So the collaboration between those different orgs (and eventually with Linus) is sort of a layer on top of the normal git workflow.

I think you can see "federation" patterns (i.e. where orgs/servers/hubs/etc are p2p but each user belongs to a particular hub) pretty often in decentralised systems - and my subjective impression is that they are a lot more successful than "true" p2p systems (where users themselves are p2p).

Other examples of that pattern would be IRC, Mastodon, email and in a limited sense the web itself (users are bound to a platform but platforms can interface with other platforms via APIs)

Crypto (and git) would be sort of hybrids: It's technically possible to use the system without a hub, but the vast majority of users goes through a hub - for crypto, those would be cloud wallets and the exchanges we're talking about...