Re: [PATCH v2 14/24] pack-bitmap: write multi-pack bitmaps

> > > It's only necessary now (at least for determining a preferred pack if
> > > the caller didn't specify one with `--preferred-pack`) because we care
> > > about reading the `num_objects` field, which the index must be loaded
> > > for.
> >
> > I guess I'm a little confused about "now" in your sentence. I understand
> > that it's not necessary before your series to have loaded all of the
> > index files ahead of time. But didn't we need to do so in v2 of your
> > series, which has the preferred-pack logic?
> >
> > If so, then was the v2 version buggy, since it only called
> > prepare_midx_pack() and not open_pack_index()? And then v3 is fixing
> > that? Or is something else opening the pack index for us?
> 
> In earlier versions of this series, I don't think we needed to have the
> indexes loaded by this point, since (before v3) we didn't care about
> ignoring the empty packs when finding a default preferred-pack.
> 
> But now we do, and so we need to call open_pack_index() ourselves.
> Confusingly, we only need to do that on packs that *are* included in the
> MIDX, since prepare_midx_pack() doesn't do it for us, but
> add_pack_to_midx() does.