| Message ID | e81296f8ccf8b47758d0ec4fbb04f0f2b356b490.1717023301.git.me@ttaylorr.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 33e9218ffbc98618896587d72eab18178f483a17 |
| Headers | show |
| Series | midx-write: miscellaneous clean-ups for incremental MIDXs | expand |
On Wed, May 29, 2024 at 06:55:28PM -0400, Taylor Blau wrote: > The function `compute_sorted_entries()` is broadly responsible for > building an array of the objects to be written into a MIDX based on the > provided list of packs. > > If we have loaded an existing MIDX, however, we may not use all of its > packs, despite loading them into the ctx->info array. > > The existing implementation simply skips past the first > ctx->m->num_packs (if ctx->m is non-NULL, indicating that we loaded an > existing MIDX). This is because we read objects in packs from an > existing MIDX via the MIDX itself, rather than from the pack-level > fanout to guarantee a de-duplicated result (see: a40498a1265 (midx: use > existing midx when writing new one, 2018-07-12)). Hmm, if the last patch had not removed the separate array/nr pair for packs, then you could just pass (array + start_pack, nr - start_pack). :) But I think it is probably reasonable to keep the notion of "here are all the packs" and "you are skipping some of them" clear through the call stack anyway. Especially if the notion of start_pack gets more complicated: > Future changes (outside the scope of this patch series) to the MIDX code > will require us to skip *at most* that number[^1]. So this patch seems fine to me. -Peff
diff --git a/midx-write.c b/midx-write.c index 15965ceb70..949a66e973 100644 --- a/midx-write.c +++ b/midx-write.c @@ -299,12 +299,12 @@ static void midx_fanout_add_pack_fanout(struct midx_fanout *fanout, * Copy only the de-duplicated entries (selected by most-recent modified time * of a packfile containing the object). */ -static void compute_sorted_entries(struct write_midx_context *ctx) +static void compute_sorted_entries(struct write_midx_context *ctx, + uint32_t start_pack) { uint32_t cur_fanout, cur_pack, cur_object; size_t alloc_objects, total_objects = 0; struct midx_fanout fanout = { 0 }; - uint32_t start_pack = ctx->m ? ctx->m->num_packs : 0; for (cur_pack = start_pack; cur_pack < ctx->nr; cur_pack++) total_objects = st_add(total_objects, @@ -889,7 +889,7 @@ static int write_midx_internal(const char *object_dir, { struct strbuf midx_name = STRBUF_INIT; unsigned char midx_hash[GIT_MAX_RAWSZ]; - uint32_t i; + uint32_t i, start_pack; struct hashfile *f = NULL; struct lock_file lk; struct write_midx_context ctx = { 0 }; @@ -957,6 +957,8 @@ static int write_midx_internal(const char *object_dir, } } + start_pack = ctx.nr; + ctx.pack_paths_checked = 0; if (flags & MIDX_PROGRESS) ctx.progress = start_delayed_progress(_("Adding packfiles to multi-pack-index"), 0); @@ -1054,7 +1056,7 @@ static int write_midx_internal(const char *object_dir, } } - compute_sorted_entries(&ctx); + compute_sorted_entries(&ctx, start_pack); ctx.large_offsets_needed = 0; for (i = 0; i < ctx.entries_nr; i++) {
The function `compute_sorted_entries()` is broadly responsible for building an array of the objects to be written into a MIDX based on the provided list of packs. If we have loaded an existing MIDX, however, we may not use all of its packs, despite loading them into the ctx->info array. The existing implementation simply skips past the first ctx->m->num_packs (if ctx->m is non-NULL, indicating that we loaded an existing MIDX). This is because we read objects in packs from an existing MIDX via the MIDX itself, rather than from the pack-level fanout to guarantee a de-duplicated result (see: a40498a1265 (midx: use existing midx when writing new one, 2018-07-12)). Future changes (outside the scope of this patch series) to the MIDX code will require us to skip *at most* that number[^1]. We could tag each pack with a bit that indicates the pack's contents should be included in the MIDX. But we can just as easily determine the number of packs to skip by passing in the number of packs we learned about after processing an existing MIDX. [^1]: Kind of. The real number will be bounded by the number of packs in a MIDX layer, and the number of packs in its base layer(s), but that concept hasn't been fully defined yet. Signed-off-by: Taylor Blau <me@ttaylorr.com> --- midx-write.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)