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

From: Shawn Pearce <spearce@spearce.org>
Date: Oct 31, 2006, 06:39 UTC
Message-ID: <20061031063941.GB7375@spearce.org>
In-Reply-To: <7v7iyhrsoi.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:

Show 18 quoted lines

> Nicolas Pitre <nico@cam.org> writes:
> 
> > 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.
> 
> I like it.
> 
> Because that approach assumes recieve-pack and unpack-objects
> and index-pack are from the same vintage (otherwise your
> receive-pack would need to have a way to see if unpack-objects
> and index-pack would grok --pack_header argument), we could even
> get away without passing the pack version if we wanted to.

Heh. On Saturday I almost did exactly what Nico proposes above. But I thought both of you would find the --pack_header=x,y option too brittle and would reject the change.

But since all three of us liked the same idea I'll code it up and resend my receive-pack patch using Nico's suggestion instead. Hopefully I'll get it out tomorrow.

BTW I think we do need to pass the pack version in the option. If we ever do increment the pack version its going to be after this option is introduced so supporting the option does not imply that the callee is able to parse the pack file without knowing what version the file is, especially if the callee supports both the current version and the new version.