On Mon, Jan 06, 2014 at 08:37:49AM -0800, Junio C Hamano wrote: > Jeff King <p...@peff.net> writes: > > > We could probably teach index-pack an "--assume-refs-are-thin" > > option to optimize for this case, and have fetch-pack/receive-pack pass > > it whenever they know that delta-base-offset was negotiated. > > I thought the existing negotiation merely means "I understand offset > encoded bases, so you are allowed to use that encoding", not "I will > not accept encoding other than the offset format, so you must use > that encoding for everything".
You are right about what it means. But this is an optimization, not a correctness thing. So if we assume that senders who are allowed to send offsets will generally do so, it might be a reasonable optimization to guess that ref-delta objects will need thin completion. If we are wrong, the worst case is that we add an extra local object to the end of the pack. So as long as we are right most of the time, it may still be a win. Of course, it may also be possible to simply multi-thread the thin-completion portion of index-pack. That would be even better, though I am not sure how it would work. The resolution of an object in one thread can always become the input for another thread. But maybe we could have each thread come up with a proposed set of objects to add to the pack, and then drop duplicates or something. I haven't looked closely. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
