There are some real world problems with that: * Many networks limit access between wireless clients, preventing the connection between develop ER machines. * Host based firewalls often prevent services from listening on client machines. Getting security exceptions for this can be difficult to impossible in some organizations. * Discovery and initial remote config can be painful. While largely trivial from a technical perspective, this kind of thing can cause resistance from many end users.

I'm not arguing against your suggestion, but these are things that need to be solved if this workflow is ever going to see mainstream adoption. Network infrastructure and security has been geared towards centralization for a long time. That's going to need to change if we want to empower distributed applications of this nature (which I believe we do).

> I'm not arguing against your suggestion

Well, actually I wasn't suggesting that, just emphasizing git's distributed nature.

What I do suggest is a federated model, large number of small hosts akin to Mastodon. What would be the real issue is, like you noted, discovery. Centralized solutions have it nicely solved but it's hard to do in general with decentralized ones.

What is this built in server git has? I thought sharing git repos over a network was depending on OpenSSH or similar.

git-daemon i assume. https://git-scm.com/docs/git-daemon

probably thinking about git-daemon (for git:// urls)

Yes, acutely git daemon can be used to serve via http(s) too.