5 ms·

Git already is p2p. The whole centralized-git-through-github-or-whatnot is a fairly recent invention. Originally you'd pull directly from other developers repos

by Doxin 6y ago

Git already is p2p. The whole centralized-git-through-github-or-whatnot is a fairly recent invention. Originally you'd pull directly from other developers repositories. The role of PR was fulfilled by emailing patchsets around. All github does is provide convenience. If you want to use github in a peer-to-peer fashion all the tools are already there.

YetAnotherNick 6y ago
Stop inventing stories. How do I pull from developer's repo? Don't say every author will need to host some server with ssh. Imagine the rate at which unmaintained repos will become unavailable.
- vertex-four 6y ago
  You've got this the wrong way round. Someone hosts a mailing list and some "canonical" repo - e.g. Linus's Linux tree - authors post patches to the mailing list. If you want to see every patch ever submitted you subscribe to the mailing list, and your mail server holds a copy of them all. You can download archives of the mailing lists via public-inbox and suchlike. And when you want to work on it, you grab Linus's tree. The vast majority of Linux developers don't have their own publicly-accessible repository that you can pull from - they push patches to the mailing list. Various archives can host copies of the mailing lists (you can ask https://www.mail-archive.com https://www.mail-archive.com to do so for you), and the git repository can obviously be mirrored anywhere anyone who can clone it likes. Congratulations, you now have a globally mirrored, decentralised development process where the canonical repo and any patches submitted never disappear.
- wyattpeak 6y ago
  I can't tell if you're being sarcastic or not. Yes, maintainers had to host servers. Yes, unmaintained repos disappeared.
  - Sir_Substance 6y ago
    That also depended on the project. With the right ports forwarded on your home router, servers can pop up and down as required. Mercurial had a single command for this, "hg serve", that would just pop up a webserver for sharing. It was extremely useful for me during university, and I've often considered it a key failing that git does not provide a similar command out of the box. As a result, the distributed nature of git is hidden from a lot of people. For the record, the command to make git do what mercurial does with hg serve is "git daemon --reuseaddr --base-path=. --export-all --verbose --enable=receive-pack". Obviously this is insecure and anyone who can establish a connection can push and pull from your repo, but if you're just jamming with some friends you don't need github.
- darau1 6y ago
  He didn't invent anything. All github or gitlab do is host that server for you, and give you access to it. You don't even have to "host a server". Simply allowing ssh access to your machine is enough.
- capableweb 6y ago
  You pull (or clone) by doing `git clone $path` where $path can be almost anything you want. A network path over NFS, a ssh path, and more. And if it's not supported, you can add support for more protocols, like IPFS, secure scuttlebutt and many more.
- zymhan 6y ago
  I can't believe someone can so totally misunderstand a 15+ year old application.
- black_puppydog 6y ago
  I see why people disagree with this, but it's a valid point IMO, if not on a technical level then on a socio-technical level. From the perspective of censorship, it's (close to) the worst idea to have one centralized... hub (hehe) to host code commons (like popcorn-time). But instead having many small hand-maintained servers, the admin of each is responsible for what's hosted on it, and of which there is no registry, doesn't sound much better. Very likely there would be a handful of effective central nodes in that network, but if you take down a couple of them, you end up with a situation where already-involved devs might still be able to navigate the landscape, but for a newcomer it might be really hard to find one of those nodes, or be sure it's one with the "right" revisions.
m4rtink 6y ago
Looks like the Pagure Git forge could be a good candidate for running as a distributed service on top of IPFS or something similar: https://pagure.io/pagure https://pagure.io/pagure This is because Pagure stores not just code but also all the project metadata (issues, PRs, Wiki pages, etc.).¨ In comparison most other git forges, including the big ones (GitHub/GitLab) store all project metadata in a central database, so if you want to move or even backup/restore a project you need to do a complicated export/import process. In comparison on Pagure you can just clone the repo and get all the project data with it. Then just put it on another Pagure instance - done. Should not be hard to adapt this system to be backed by a distributed system from below.
parliament32 6y ago
That's not p2p though. You're still pulling from a centralized place, it just happens to be in the dev's basement. Proper p2p would be like joining a DHT swarm with a hash and downloading pieces from other peers.

by Doxin 6y ago

YetAnotherNick 6y ago

Stop inventing stories. How do I pull from developer's repo? Don't say every author will need to host some server with ssh. Imagine the rate at which unmaintained repos will become unavailable.

vertex-four 6y ago
You've got this the wrong way round. Someone hosts a mailing list and some "canonical" repo - e.g. Linus's Linux tree - authors post patches to the mailing list. If you want to see every patch ever submitted you subscribe to the mailing list, and your mail server holds a copy of them all. You can download archives of the mailing lists via public-inbox and suchlike. And when you want to work on it, you grab Linus's tree. The vast majority of Linux developers don't have their own publicly-accessible repository that you can pull from - they push patches to the mailing list. Various archives can host copies of the mailing lists (you can ask https://www.mail-archive.com https://www.mail-archive.com to do so for you), and the git repository can obviously be mirrored anywhere anyone who can clone it likes. Congratulations, you now have a globally mirrored, decentralised development process where the canonical repo and any patches submitted never disappear.
wyattpeak 6y ago
I can't tell if you're being sarcastic or not. Yes, maintainers had to host servers. Yes, unmaintained repos disappeared.
- Sir_Substance 6y ago
  That also depended on the project. With the right ports forwarded on your home router, servers can pop up and down as required. Mercurial had a single command for this, "hg serve", that would just pop up a webserver for sharing. It was extremely useful for me during university, and I've often considered it a key failing that git does not provide a similar command out of the box. As a result, the distributed nature of git is hidden from a lot of people. For the record, the command to make git do what mercurial does with hg serve is "git daemon --reuseaddr --base-path=. --export-all --verbose --enable=receive-pack". Obviously this is insecure and anyone who can establish a connection can push and pull from your repo, but if you're just jamming with some friends you don't need github.
darau1 6y ago
He didn't invent anything. All github or gitlab do is host that server for you, and give you access to it. You don't even have to "host a server". Simply allowing ssh access to your machine is enough.
capableweb 6y ago
You pull (or clone) by doing `git clone $path` where $path can be almost anything you want. A network path over NFS, a ssh path, and more. And if it's not supported, you can add support for more protocols, like IPFS, secure scuttlebutt and many more.
zymhan 6y ago
I can't believe someone can so totally misunderstand a 15+ year old application.
black_puppydog 6y ago
I see why people disagree with this, but it's a valid point IMO, if not on a technical level then on a socio-technical level. From the perspective of censorship, it's (close to) the worst idea to have one centralized... hub (hehe) to host code commons (like popcorn-time). But instead having many small hand-maintained servers, the admin of each is responsible for what's hosted on it, and of which there is no registry, doesn't sound much better. Very likely there would be a handful of effective central nodes in that network, but if you take down a couple of them, you end up with a situation where already-involved devs might still be able to navigate the landscape, but for a newcomer it might be really hard to find one of those nodes, or be sure it's one with the "right" revisions.

m4rtink 6y ago

Looks like the Pagure Git forge could be a good candidate for running as a distributed service on top of IPFS or something similar: https://pagure.io/pagure https://pagure.io/pagure This is because Pagure stores not just code but also all the project metadata (issues, PRs, Wiki pages, etc.).¨ In comparison most other git forges, including the big ones (GitHub/GitLab) store all project metadata in a central database, so if you want to move or even backup/restore a project you need to do a complicated export/import process. In comparison on Pagure you can just clone the repo and get all the project data with it. Then just put it on another Pagure instance - done. Should not be hard to adapt this system to be backed by a distributed system from below.

parliament32 6y ago

That's not p2p though. You're still pulling from a centralized place, it just happens to be in the dev's basement. Proper p2p would be like joining a DHT swarm with a hash and downloading pieces from other peers.