Re: clone: I'm only doing a max of 256 requests

From: Junio C Hamano <junkio@cox.net>
Date: Oct 5, 2005, 23:45 UTC
Message-ID: <7vek6zedea.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0510051541300.31407@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

> No, just change the "MAX_NEEDS" define from 256 to some larger value.
>
> There's no real reason for the limit, except that maybe we should have 
> some dynamic allocation for this.

If somebody is asking for more than say 20 refs, even if the repository is mature and has 1000 point releases tagged, it might not make that much of a difference if we ship everything back instead of being selective, especially when the downloader said "I do not have anything", i.e. initial cloning.

So after the 'rev-list --all' patch, I was actually going to suggest reducing MAX_NEEDS, to say 47 (another arbitrary number), and maybe making MAX_HAS side dynamic to hold more refs for the stop list.

Also it may be worthwhile to teach upload-pack.c::got_sha1() to notice when the other side says he has one object and we know that object is reachable from another object he already said he has, and choose not to use the older object on the has_sha1[] list. The "have" list from fetch-pack tends to come from newer to older, so this would save has_sha1[] array entries from being consumed by older commits when we know about the commits he has near the tip of the same branch.