On Tue, Mar 18, 2025 at 09:30:14AM -0700, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> 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
