On Mon, Mar 25, 2024 at 01:24:44PM -0400, Taylor Blau wrote: > We could extract two functions (say, `want_included_pack()` and a > `_nonempty()` variant), but this is not necessary. For the case in > `fill_included_packs_all()` which does not check the pack size, we add > all of the pack's objects assuming that the pack meets all other > criteria. But if the pack is empty in the first place, we add all of its > zero objects, so whether or not we "accept" or "reject" it in the first > place is irrelevant. OK, that makes sense. It does mean that we call the expensive-ish open_pack_index() just to find out that it has 0 objects. But I guess if we didn't reject it at this point, we'd soon open it anyway, so it's probably not a big deal. > +static int want_included_pack(struct repository *r, > + struct multi_pack_index *m, > + int pack_kept_objects, > + uint32_t pack_int_id) I wondered about this funky pack_int_id interface, rather than just having the caller pass in the pack struct. But we need it because one of the callers needs to load the pack struct by calling prepare_midx_pack(). That should be a quick noop for the other caller, since the entry in m->packs[] will already be filled in (and if it's not, then you've just fixed a bug!). So this all looks good to me. -Peff
