From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 07 Apr 2021 22:13:39 GMT
Subject: Re: There should have be git gc --repack-arguments
Message-ID: <xmqqa6q9yc8c.fsf@gitster.g>
In-Reply-To: <YG4mImcQyTC1/S8X@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> On Wed, Apr 07, 2021 at 01:40:16PM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>> 
>> >> ... git repack ...  --max-pack-size=<desired pack size> to create split and
>> >> smaller packs instead.
>> > ...
>> > You can also set pack.packSizeLimit for the latter, though I do not
>> > recommend it. It will not help with memory usage (neither while
>> > repacking nor for later commands).
>> 
>> In other words, passing --max-pack-size, whether it is done with a
>> new --repack-arguments option or it is done with the existing
>> pack.packSizeLimit configuration, would make things worse.
>
> Right. I wish we didn't have --max-pack-size at all. I do not think it
> is ever a good idea, and it complicates the packing code quite a bit.

I suspect that the original motivation was sneaker-netting on
multiple floppy disks ;-)

>>  - on a small box, it may make sense to avoid repacking everything
>>    into one in the first place, but we do not want the number of
>>    packs to grow unbounded.
>> 
>> Would the new geometric repack feature help here, especially for the
>> latter?
>
> Yes, I think it would. You'd perhaps want to generate a multi-pack-index
> file, too, to avoid having to look for objects in multiple packs
> sequentially (we have a "git repack --write-midx" option on the way, as
> well).

Thanks.