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
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
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