Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes: >> Junio C Hamano <gitster@xxxxxxxxx> writes: >> >> >>> The optimization makes sense to me if certain >> >>> conditions are met, like... >> >>> >> >>> - Most of the time there is no missing object due to promisor, even >> >>> if has_promissor_to_remote() is true; >> >> >> >> I think that optimizing for this condition makes sense - most pushes (I >> >> would think) are pushes of objects we create locally, and thus no >> >> objects are missing. >> >> Another simple thing I missed. Why do we specifically refer to >> "push" here? Is this codepath in pack-objects not used or less >> often used by upload-pack (which is what serves "fetch")? >> >> I just wanted to make sure that we are not optimizing for "push", >> trading efficiency for "fetch" off. > > Ah...that's true. For "fetch" I think it's less important because the > multiple roundtrips of the pack negotiation means that the packfiles are > usually more specific, but this optimization will help "fetch" too. I > don't think we're optimizing at the expense of "fetch" - any > improvements should benefit both similarly. The one who serves "fetch" (i.e. "upload-pack") may be advertising the objects that it itself would have to lazily fetch from its promisor remote, but that is sort of crazy. As long as we have something to discourage such an arrangement (i.e. "don't fetch from a lazy clone"), we would be OK to assume that most of the time there is no missing objects. Thanks.
