On 09/04/10 17:56, Bernhard R. Link wrote: > Assume you are looking to update abranch B built on top of some > say arm-specific branch A based on top of the main-line kernel L. > > There you have 6 types of peers: > > 1) those that have the current branch B > 2) those that have an older state of B > 3) those that have the current branch A > 4) those that have an older state of A > 5) those that have the current branch L > 6) those that have an older state of L. > > Assuming you want a quite obscure branch, type 1 and 2 peers will not > be that many, so would be nice if there was some way to also get stuff > from the others. > > Peers of type 6 do not interest you, as there will be enough of type 5. > > But already peers of type 3 might not be much and even less of type 1 > so types 2 and 4 get interesting. > > If you get first a tree of all commit-ids you still miss (you only > need that information once and every peer of type 1 can give it to you) > and have somehow a way to look at the heads of each peer, it should be > streight forward to split the needed objects using your way (not specifying > the head you have but the one you hope to get from others), they should be > able to send you a partial pack in the way you describe. Actually, since the seeds of this quite obscure branch know that this branch is rare and are most likely also sharing other, much more popular, refs, they can just add another note to the initial reply, saying "this_ref_is_descendant_of($popular_branch, $common_base)". Then the client can fetch old..$common_base and $common_base..$rare_head independently (even in parallel). 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