Subject: Re: git pack/unpack over bittorrent - works!

From: Artur Skawina <[email-masked]>
Date: Sat, 04 Sep 2010 03:52:59 +0200

Hmm, taking a few steps back, what is the expected usage of git-p2p?
Note it's a bit of a trick question; what i'm really asking is what _else_,
other than pulling/tracking Linus' kernel tree will/can be done with it?

Because once you accept that all peers are equal, but some peers are more
equal than others, deriving a canonical representation of the object store
becomes relatively simple. Then, it's just a question of fetching the missing
bits, whether using a dumb (rsync-like) transport, or a git-aware protocol.
(I've no idea why you'd want to base a transfer protocol on the unstable packs,
building it on top of objects seems to be the only sane choice)

I'm mostly git-ignorant and i'm assuming the following two things -- if someone
more familiar w/ git internals could confirm/deny, that would be great:

1) "git pull git:..." would (or could be made to) work w/ a client that asks for
   "A..E", but also tells the server to omit "B,C and D" from the wire traffic.    

2) Git doesn't use chained deltas. IOW given commits "A --d1-> B --d2-> C",
   "C" can be represented as a delta against "A" or "B", but _not_ against "d1". 
   (Think of the case where "C" reverts /part of/ "B")

Then there are security implications... Which pretty much mandate having "special"
peers anyway, at least for transferring heads (branches/tags etc). Which means
the second paragraph above applies. And as the "special peer" in practice can be
just a signed tag/commit, like "v2.6.35", it's not such a big limitation like it
may seem at first...

artur