From: Taylor Blau <me@ttaylorr.com>
Date: Wed, 19 Mar 2025 22:40:39 GMT
Subject: Re: [PATCH 5/5] repack: begin combining cruft packs with `--combine-cruft-below-size`
Message-ID: <Z9tH5zbZ/eWC1e6p@nand.local>
In-Reply-To: <xmqqh63q47zd.fsf@gitster.g>

On Tue, Mar 18, 2025 at 09:30:14AM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > @@ -81,6 +81,14 @@ to the new separate pack will be written.
> >  	`--max-pack-size` (if any) by default. See the documentation for
> >  	`--max-pack-size` for more details.
> >
> > +--combine-cruft-below-size=<n>::
> > +	When generating cruft packs without pruning, only repack
> > +	existing cruft packs whose size is strictly less than `<n>`.
> > +	Cruft packs whose size is greater than or equal to `<n>` are
> > +	left as-is and not repacked. Useful when you want to avoid
> > +	repacking large cruft pack(s) in repositories that have many
> > +	and/or large unreachable objects.
> > +
>
> Shared with existing entries in this file, but let's strive to make
> sure we explicitly mention units.  --max-cruft-size=<n> is explained
> to cramp below '<n>' bytes, which is great, --max-pack-size=<n> says
> it accepts k/m/g suffixes and its minimum size is 1 MiB, which is
> explicit enough hint that this is counted in bytes.  This new entry
> should hint that this is also counted in bytes.

Definitely an oversight on my part, I certainly agree with this
sentiment.

FWIW, '--max-cruft-size' no longer explicitly says "in bytes", but
mostly because it (a) doesn't describe `<n>` at all, because (b) it
refers readers to the documentation on `--max-pack-size`. No need to
cover it twice there.

Thanks,
Taylor