Re: git pack/unpack over bittorrent - works!

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