On Sat, Aug 13, 2022 at 12:52 AM Derrick Stolee <derrickstolee@xxxxxxxxxx> wrote: > > So really, the problem is that we are handling the r->objects->packed_git > list instead of an array of packs that are under the control of the new > midx. This assumption is baked deep in the pack-objects flow, so it > would be hard to separate this idea. > > Perhaps doing the reprepare_packed_git() to regenerate the list would be > sufficient as a band-aid for now, but we would want to later do the big > dig of focusing the pack_data struct to a specific list of pack-files > (by default the set from get_all_packs(), but for midx bitmaps we can > supply a specific set of packs). `reprepare_packed_git()` can not stop it. Because this function updates `r->objects->packed_git` list (i.e. it reloads packs that are not in the old midx) and as I said before, we are setting `->index` for only r->objects->packed_git not ctx.info[id].p. So, it will call the `oe_map_new_pack()` function in either way. I have tested it. One thing that really worries me is what if the failure is not related to calling `oe_map_new_pack()? I did all my work assuming that this function is the culprit. But I don't know if it is.
