Re: [PATCH] Teach receive-pack how to keep pack files when unpacklooseobjects = 0.

[Nicolas Pitre <nico@cam.org>]

On Mon, 30 Oct 2006, Junio C Hamano wrote:

> One thing you can cheaply do is to tell the number of new
> commits that is coming to receive-pack from send-pack when it
> sends the old..new pairs before it sends the packfile payload.
> It would be just a single internal rev-list call inside
> send-pack, which is reasonably cheap.

Well, it could even be avoided.

> If the receiving end knows how to process that new information
> (invent a "send-count" protocol extension and send it just like
> we already send "report-status" request), send one extra packet
> after flushing the list of old..new from send-pack to
> receive-pack, to tell what the number of commits are, and make a
> matching change in receive-pack.

I don't like this much since a commit can carry along very little or 
very large amount of objects.  You really want to decide on the number 
of objects.

Why not just parse the pack header in receive-pack / fetch-pack, and 
decide on the first-hand information?  Sure the pack header is then 
gone, but then the only thing that is needed is an extra flag to both 
unpack-objects and index-pack to tell them that we've already parsed the 
pack header and that the pack version is x and the number of objects is 
y.  Simply something like --pack_header=x,y.  No protocol extension 
needed, no extra rev-list, no reliance on the remote server providing 
the needed info.