Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: auto gc again

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:44:24

Nicolas Pitre [off-list ref] writes:
On Wed, 19 Mar 2008, Junio C Hamano wrote:
quoted
Linus Torvalds [off-list ref] writes:
quoted
On Wed, 19 Mar 2008, Junio C Hamano wrote:
...
quoted
 - 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help