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

From: Nicolas Pitre <nico@cam.org>
Date: Oct 31, 2006, 04:08 UTC
Message-ID: <Pine.LNX.4.64.0610302258400.11384@xanadu.home>
In-Reply-To: <7vlkmxtmln.fsf@assigned-by-dhcp.cox.net>

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

Show 5 quoted lines

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

Show 6 quoted lines

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