Re: [PATCH v4 0/6] pack-objects: freshen objects with multi-cruft packs
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 13, 2025, 15:12 UTC
- Message-ID
- <xmqqr031q80i.fsf@gitster.g>
- In-Reply-To
- <20250313062951.GA96035@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 17 quoted lines
> But do we actually care about eventually having a series of 40MB packs? > Or do we care about having some cutoff so that we don't rewrite those > first 40MB on subsequent repacks? > > If the latter, then for step 2, what if we don't feed a max size? We'd > end up with one 60MB pack (again, having written all of the bytes once). > And on the next repack we'd leave it be (since it's over the threshold). > We'll start forming new packs, which will eventually aggregate to 40MB > (or possibly larger). > > If I understand the main purpose of the series, it is that we must > rescue objects out of cruft packs if they became fresher (by having > loose copies made). But that is orthogonal to max pack sizes, isn't it? > We just need for pack-objects to be fed those objects (which should be > happening already) and decide _not_ to omit them based on their presence > in the kept cruft packs (based on the mtime in those cruft packs, of > course). Which looks like what your want_cruft_object_mtime() is doing.
Yeah, no packsize limit on the output side, but making sure that the decision to roll up existing cruft packs is made sensibly, is what the above gives us, which I life a lot. The one-before and -after confusion came exactly because we somehow tried to have threshold on the output side.