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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html