Re: auto gc again

[Nicolas Pitre <nico@cam.org>]

On Wed, 19 Mar 2008, Junio C Hamano wrote:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > On Wed, 19 Mar 2008, Junio C Hamano wrote:
> >> 
> >> Having said that, I am not sure how the auto gc is triggering for your
> >> (presumably reasonably well maintained) repository that has only small
> >> number of loose objects.  I haven't seen auto-gc annoyance myself (and
> >> git.git is not the only project I have my git experience with), and Linus
> >> also said he hasn't seen breakages.
> >
> > I think it was 'autopacklimit'.
> >
> > I think the correct solution is along the following lines:
> >
> >  - disable "git gc --auto" entirely when "gc.auto <= 0" (ie we don't even 
> >    care about 'autopacklimit' unless automatic packing is on at all)
> >
> >    Rationale: I do think that if you set gc.auto to zero, you should 
> >    expect git gc --auto to be disabled.
> 
> Sensible, I would say.

Seconded.

> >  - make the default for autopacklimit rather higher (pick number at 
> >    random: 50 instead of 20).
> >
> >    Rationale: the reason for "git gc --auto" wasn't to keep things 
> >    perfectly packed, but to avoid the _really_ bad cases. The old default 
> >    of 20 may be fine if you want to always keep the repo very tight, but 
> >    that wasn't why "git gc --auto" was done, was it?
> 
> I do not think "very tight" was the reason, but on the other hand, my
> personal feeling is that 20 was already 10 too many pack idx files we have
> to walk linearly while looking for objects at runtime.

Since commit f7c22cc68ccb this is no longer such an issue.

> Each auto gc that sees too many loose objects will add a new packfile (we
> do not do "repack -a" for obvious reasons) that would hopefully contain
> 6-7k objects, so you would need to generate 120-140k objects before
> hitting the existing 20 limit.
> 
> And then auto gc will notice you have too many packs, and "repack -A" to
> pack them down in a single new pack, and you are back to "single pack with
> less than 6-7k loose objects" situation for the cycle to continue.
> 
> At least, that is the theory.

Note that the current fetch.unpackLimit might play a role as well, 
especially if you fetch often (often meaning that you're more likely to 
have the received pack exploded into loose objects, or you're 
accumulating many small packs).


Nicolas