3 ms·

It would be wonderful if it were distributed by default more easily. For instance, an ipfs or torrent backend which automatically provides a backbone of thousa

by chaxor 3y ago

It would be wonderful if it were distributed by default more easily. For instance, an ipfs or torrent backend which automatically provides a backbone of thousands of computers with the repo on them as the remote, rather than just the single github server. Ipfs remote for git should be the default.

wepple 3y ago
How reliable is IPFS for things like this? If I wanted to use git on ipfs, I could host a node and push all my git commits there, but I’d have to convince others to host it as well, correct? So perhaps it would be awesome for majorly popular projects, but still a end up having a SPOF for smaller projects right?
- chaxor 3y ago
  The idea is to have the daemon automatically start and serve the git repo anytime a git clone is done, that way the number of nodes hosting the repo (speed of download) grows with the popularity of the repo. That way you could saturate a 10G connection on a popular repo, whereas with github you'll likely be pretty throttled or limited.
palata 3y ago
It was designed around the email workflow, which is distributed by default: you send your patches to a mailing list, which is distributed between all the email servers and clients. And it's easy to host mirrors, too. GitHub and the PR workflow tend to make it all centralized.
- chaxor 3y ago
  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.
  - palata 3y ago
    > 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.
    - chaxor 3y ago
      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.
      - palata 3y ago
        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?

by chaxor 3y ago

wepple 3y ago

How reliable is IPFS for things like this? If I wanted to use git on ipfs, I could host a node and push all my git commits there, but I’d have to convince others to host it as well, correct? So perhaps it would be awesome for majorly popular projects, but still a end up having a SPOF for smaller projects right?

chaxor 3y ago
The idea is to have the daemon automatically start and serve the git repo anytime a git clone is done, that way the number of nodes hosting the repo (speed of download) grows with the popularity of the repo. That way you could saturate a 10G connection on a popular repo, whereas with github you'll likely be pretty throttled or limited.

palata 3y ago

It was designed around the email workflow, which is distributed by default: you send your patches to a mailing list, which is distributed between all the email servers and clients. And it's easy to host mirrors, too. GitHub and the PR workflow tend to make it all centralized.

chaxor 3y ago
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.
- palata 3y ago
  > 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.
  - chaxor 3y ago
    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.
    - palata 3y ago
      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?