Re: [PATCH 2/2] Teach receive-pack how to keep pack files based on object count.

From: Shawn Pearce <spearce@spearce.org>
Date: Oct 31, 2006, 21:29 UTC
Message-ID: <20061031212942.GA24184@spearce.org>
In-Reply-To: <Pine.LNX.4.64.0610311559150.11384@xanadu.home>

Nicolas Pitre <nico@cam.org> wrote:

Show 24 quoted lines

> On Tue, 31 Oct 2006, Shawn Pearce wrote:
> > Nicolas Pitre <nico@cam.org> wrote:
> > > I think this should be solved before rx packs are actually stored as 
> > > packs though.  Otherwise people will end up with unwanted .keep files 
> > > left around.  Maybe having a much bigger default for object number 
> > > treshold for the time being?  (unless this patch is applied to "next" at 
> > > the same time as another one that actually deals with those .keep 
> > > files).
> > 
> > Its next on my list of things to do.  Hopefully I'll be able to
> > implement it today.
> > 
> > I'm thinking of just brute forcing it: put enough identifying data
> > into the .keep file to make it unique, then go through every local
> > pack and look at their .keep file; if the content matches what
> > receive-pack asked index-pack to put there then remove it.
> 
> Ouch.  What about the patch below?  It covers only the pull/fetch case, 
> but covering the push case shouldn't be that hard either (simply use a 
> pipe to read index-pack's stdout and capture the pack name).
> 
> I used "pack" <tab> <sha1> so it is easy to pick out of the list of refs 
> that usually comes over the stream in the fetch case (if I understood 
> that part right).

I thought about using a pipe too, but in the case of receive-pack it looked like index-pack was sending something back to the push end of the connection. I didn't dig into the code enough to see what that was and how to do the same in receive-pack itself. The brute force approach is horrible but simple. ;-)

I'll look at your patch and what I need to do make a pipe work here, because its clearly the better solution.