Re: There should have be git gc --repack-arguments

From: Jeff King <peff@peff.net>
Date: Apr 7, 2021, 22:22 UTC
Message-ID: <YG4ws7PiKKKjPUff@coredump.intra.peff.net>
In-Reply-To: <xmqqa6q9yc8c.fsf@gitster.g>

On Wed, Apr 07, 2021 at 03:13:39PM -0700, Junio C Hamano wrote:

Show 13 quoted lines

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

That had always been my impression, too. But when I looked in the archive while writing my earlier reply, most of the discussion near --max-pack-size had to do with the early index limitations.

If you are sneaker-netting, you are probably better off to just split the pack at byte boundaries with an external tool anyway, for two reasons:

  - our max-pack-size is just a guideline. It only splits at object
    boundaries so if you have an object bigger than the max, we'll
    exceed it.

  - dedicated splitting tools often have useful extra features, like
    k-of-n error correction.

Besides, if you are sneaker netting you'd want to use a bundle, and I don't think bundles support max-pack-size. :)

Anyway, all off-topic but an interesting diversion.

-Peff