Sure, but the work of typing out 1000 people's IP addresses as remotes and managing that sounds like a nightmare that should be offloaded somehow. Adding "ipfs" to the remote and having it managed by a system to push to thousands of devices (however many have cloned the repo) is much more concise and simple.
> the work of typing out 1000 people's IP addresses as remotes and managing that sounds like a nightmare
Not sure I get that. You do `git send-email --to=<mailing-list-address>` and that's it. Everyone on the mailing list gets a copy of your patch, that they can apply if they want.
Wow, perhaps I am unaware of some of the wonderful capabilities of git!
So if everything on the entirety of github.com was deleted, you could still do a git clone somehow and it would pull it from everyone who has ever cloned that repo?
Because that's what I'm referring to here - p2p not hub-spoke architectures.
I'm fairly certain git doesn't inherently have this feature, unless the backend remote could automatically start an iOS or torrent daemon and deal with torrent or ipfs for pulling and pushing.
I am talking about the collaboration process: sharing patches with collaborators.
I think you are talking about distributing the git server itself over p2p. Which I find less important because I don't think that the server bandwidth is usually a problem. Or is it?
