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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicolas Pitre <nico@xxxxxxx> wrote:
> On Tue, 31 Oct 2006, Shawn Pearce wrote:
> 
> > Since keeping a pushed pack or exploding it into loose objects
> > should be a local repository decision this teaches receive-pack
> > to decide if it should call unpack-objects or index-pack --stdin
> > --fix-thin based on the setting of receive.unpackLimit and the
> > number of objects contained in the received pack.
> 
> This works fine when used with my replacement patch for your [1/2] one.
> 
> > Currently this leaves every received pack as a kept pack.  We really
> > don't want that as received packs will tend to be small.  Instead we
> > want to delete the .keep file automatically after all refs have
> > been updated.  That is being left as room for future improvement.
> 
> 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.

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]