Re: auto gc again

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 19, 2008, 23:25 UTC
Message-ID: <7vd4pq1el3.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.1.00.0803191910170.2947@xanadu.home>

Nicolas Pitre <nico@cam.org> writes:

Show 19 quoted lines

> 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:
>> ...
>> >  - 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.

Notice that I did not say "19 too many". I know f7c22cc (always start looking up objects in the last used pack first, 2007-05-30) was meant to alleviate the situation, but isn't "no longer" a gross exaggeration?

> 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).

Ah, yes, native fetch will also result in a new pack, so even if you do not do anything else, if you fetch once a day, you will accumulate 20 packs in that many days.