Re: [PATCH v5 3/6] pack-bitmap-write: learn pack.writeBitmapLookupTable and add tests

From: Abhradeep Chakraborty <chakrabortyabhradeep79@gmail.com>
Date: Aug 13, 2022, 10:59 UTC
Message-ID: <CAPOJW5z99b0_NGBYDbZUvmzbWECJKxGvB4RffoPJYszfFB0cEg@mail.gmail.com>
In-Reply-To: <179c0d30-ccb1-36cf-f783-814c9c8d84c2@github.com>

On Sat, Aug 13, 2022 at 12:52 AM Derrick Stolee <derrickstolee@github.com> wrote:

Show 11 quoted lines

>
> 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.