Re: [PATCH v4 4/6] pack-objects: generate cruft packs at most one object over threshold

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Mar 12, 2025 at 1:43 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Elijah Newren <newren@xxxxxxxxx> writes:
>
> > Would it make sense to break the assumption that --max-cruft-size ==
> > --max-pack-size and perhaps rename the former?  I think the problem is
> > that the two imply different things (one is a minimum, the other a
> > maximum), and thus really should be different values.  E.g.
> > --combine-cruft-below-size that is set to e.g. half of
> > --max-pack-size, and then you can continue combining cruft packs
> > together until they do go above the cruft threshold, while avoiding
> > actually exceeding the pack size threshold?
>
> With below-size and max-size set to say 180 and 200 respectively, an
> attempt to combine the crufts may end up filling a cruft pack to 170
> but the smallest of the remaining cruft may weigh 40, which means
> including it would cause the max-size to be exceeded.  In such a
> scenario, there may not be a solution to satisfy given constraints,
> i.e. go above the below-size without stay below the max-size.
>
> So I am not sure if the approach would really solve much.
>
> Other than that a separate names, especially losing "max" from the
> threshold that really does not mean "max", would solve the confusion
> that comes from naming, that is.

--max-pack-size is a constraint.  --combine-cruft-below-size is not.
Think particularly of the case where the user doesn't even have any
cruft packs yet and has only accumulated a little bit of cruft.  That
option is merely a guide post to say that if it's smaller than that
size, then feel free to keep trying to add to it (so long as it
doesn't violate constraints such as --max-pack-size).





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux