Re: [PATCH] change the unpack limit treshold to a saner value

On Wed, 6 Dec 2006, Linus Torvalds wrote:

We have a much easier time handling many loose packed objects than many 
pack-files. For many reasons, but two really obvious ones:

 - pack-file indexes get read in on startup, and we maintain an explicit 
   list of them. Having lots of pack-files adds overhead that doesn't 
   exist for lots of loose objects.

 - loose files are spread out over 256 subdirectories to make lookup 
   easier, packfiles are not (and always create an index file too).

So in general, as a trivial heuristic, you probably want about 512 times 
as many loose objects as you want pack-files, i fonly because of the 
latter issue, because you can much more easily handle lots of loose 
objects than lots of pack-files. So it's _not_ a factor of 3. Or even 10.

But since there _is_ reason to do pack-files too, and since using too big 
a value means that you never end up keeping a pack-file _at_all_ if you 
pull often, I'd suggest that rather than use a limit of 512 you go for 
something like 100-200 objects as the threshold (of course, the proper one 
would depend on the distribution of the size of your pack-files, but I'll 
just hand-wave and say that together with occasional re-packing, something 
in that range is _generally_ going to be a good idea).

Note that this setting is currently observed for pushes not pulls.
On the pull side you currentli need to provide -k for not exploding 
packs.

So the question is what number of objects on average do pushes have?  If 
most pushes are below the treshold this is not going to be really 
useful.

And I think 5000 is definitely way too high.  10 might be too small 
indeed.  100 is maybe a good default to try out.