Re: [PATCH v4 0/6] pack-objects: freshen objects with multi-cruft packs

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2025, 20:13 UTC
Message-ID: <xmqqr0332un3.fsf@gitster.g>
In-Reply-To: <cover.1741648467.git.me@ttaylorr.com>

Taylor Blau <me@ttaylorr.com> writes:

Show 15 quoted lines

> Here is a slightly larger reroll of my series to fix object freshening
> when using multi-cruft packs that I have been meaning to send for a
> couple of days.
>
> I realized after sending the last round that not only was the first
> commit from v1 flawed (for the reasons Patrick identified) but that
> there is currently no way to grow a new cruft pack past the configured
> limit.
>
> Independent of this series suppose for example that we have two 100 MiB
> packs, and the threshold is 200 MiB. We should able to in theory combine
> those packs together. But we can't! The largest pack we'll make is
> 199MiB (and change), since builtin/pack-objects.c::write_one() will
> refuse to write any object which would bust the limit given by
> --max-pack-size.

I am not sure why that is a problem. If we have many loose objects and the threshold is set at 200, wouldn't we also give up at 199 plus a change when packing these loose objects into a pack? If the last object that makes us bust the threshold is unusually large, say 50, we may give up at 150 plus a bit, unless we go back to the queue and pick smaller objects among the remaining ones to fill the remaining 50 minus a bit, and because we do not do that to enforce max-pack-size, I am not sure how "give up just before the threshold" is too bad and needs to be replaced with "give up just after".

Or is the problem that the threshold is applied differently based on where the objects come from? E.g., packing many loose objects would stop just after, but repacking from cruft would stop just before, or something? If the problem is that we are inconsistent, then I would understand that it may be good to make things consistent.

> This series resurrects the first patch from v1 after introducing a
> behavior change for 'git pack-objects --cruft --max-pack-size'. When
> given with '--cruft', '--max-pack-size' now allows pack-objects to grow
> a pack *just* past the given limit by at most one object.

And what happens when the last object appended is very large, like 70? Would we end up with 270 when the threshold says 200?

I still am not getting what you are trying to explain in the above two paragraphs, but in general, "give up just before" would be a better choice than "give up just after", exactly because the threshold we are letting the user to give is the maximum.