On Wed, Apr 07, 2021 at 03:13:39PM -0700, Junio C Hamano wrote:
> >> > 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
