Re: http://tech.slashdot.org/comments.pl?sid=1885890&cid=34358134

From: J.H. <warthog19@eaglescrag.net>
Date: Nov 29, 2010, 19:27 UTC
Message-ID: <4CF3FEB0.9040806@eaglescrag.net>
In-Reply-To: <1291025571.4262.21.camel@wpalmer.simply-domain>

> I want my version control software to use p2p concepts for efficiency. I
> don't want my version control software to be a p2p client any more than
> I want my text-editor to be a mail client.

Keep in mind that adding p2p concepts to something doesn't make it more efficient, in fact in most cases it makes it dramatically *LESS* efficient.

git-torrent like concepts have come up in the past, and I keep pointing out how and why they likely won't be useful. The biggest reason: there is no advantage for a client to stay in the cloud once they have their data. You can force this, sure, but clones are seldom and rare to begin with (as you mentioned) so there won't be a very large cloud to pull from to start with. With that in mind, I really see no advantage to p2p inside of the git core at all. It adds a lot of complexity for little gain.

Now you do mention things that would be useful:

- Ability to resume a clone that you only have a partial download for
(maybe just pack files?)
- Ability to include something like a 'meta-link' like list of
repositories to check for data (inferred from the multiple download
locations)

There are things we can learn from p2p, but I don't think adding it to git is actually useful.

Just my $0.02 though.

- John 'Warthog9' Hawley