On Wed, Mar 12, 2025 at 11:28:17AM -0700, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> writes: > > > On Tue, Mar 11, 2025 at 01:13:20PM -0700, Junio C Hamano wrote: > >> > 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. > > > > I think this is similar to the discussion earlier in the thread, but let > > me know if there is something here I'm missing. > > I think the only thing you are missing is that max specified is the > ceiling, and "you can bust it, hoping by a little but you do not > know how huge the error is" is unacceptable. I agree that in the general case it is unacceptable. I think I might see it slightly different than you, since for cruft packs the idea is to bound the working set of what you're repacking using the size of the resulting packs as a proxy for the former. Maybe we should call the option something else that makes the cruft pack use-case clearer. But in the other thread I came around to the idea that this case is too niche to address completely, so I think we can discard this round as a terrible idea. Thanks, Taylor
