From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/8] midx-write.c: support reading an existing MIDX with `packs_to_include`
Date: Wed, 29 May 2024 09:48:20 +0200 [thread overview]
Message-ID: <ZlbdxJmIBvgV_VIF@tanuki> (raw)
In-Reply-To: <61268114c6562ba882210fd94b3f336efcb5c486.1716482279.git.me@ttaylorr.com>
[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]
On Thu, May 23, 2024 at 12:38:19PM -0400, Taylor Blau wrote:
> Avoid unconditionally copying all packs from an existing MIDX into a new
> MIDX by checking that packs added via `fill_packs_from_midx()` don't
> appear in the `to_include` set, if one was provided.
>
> Do so by calling `should_include_pack()` from both `add_pack_to_midx()`
> and `fill_packs_from_midx()`.
This is missing an explanation why exactly we want that. Is the current
behaviour a bug? Is it a preparation for a future change? Is this change
expected to modify any existing behaviour?
Reading through the patch we now unconditionally load the existing MIDX
when writing a new one, but I'm not exactly sure what the effect of that
is going to be.
[snip]
> diff --git a/midx-write.c b/midx-write.c
> index 9712ac044f..36ac4ab65b 100644
> --- a/midx-write.c
> +++ b/midx-write.c
> @@ -101,27 +101,13 @@ struct write_midx_context {
> };
>
> static int should_include_pack(const struct write_midx_context *ctx,
> - const char *file_name)
> + const char *file_name,
> + int exclude_from_midx)
> {
> - /*
> - * Note that at most one of ctx->m and ctx->to_include are set,
> - * so we are testing midx_contains_pack() and
> - * string_list_has_string() independently (guarded by the
> - * appropriate NULL checks).
> - *
> - * We could support passing to_include while reusing an existing
> - * MIDX, but don't currently since the reuse process drags
> - * forward all packs from an existing MIDX (without checking
> - * whether or not they appear in the to_include list).
> - *
> - * If we added support for that, these next two conditional
> - * should be performed independently (likely checking
> - * to_include before the existing MIDX).
> - */
> - if (ctx->m && midx_contains_pack(ctx->m, file_name))
> + if (exclude_from_midx && ctx->m && midx_contains_pack(ctx->m, file_name))
> return 0;
> - else if (ctx->to_include &&
> - !string_list_has_string(ctx->to_include, file_name))
> + if (ctx->to_include && !string_list_has_string(ctx->to_include,
> + file_name))
The second branch is a no-op change, right? The only change was that you
converted from `else if` to `if`. I'd propose to either keep this as-is,
or to do this change in the preceding patch already that introduces this
function.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-05-29 7:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 16:37 [PATCH 0/8] midx-write: miscellaneous clean-ups for incremental MIDXs Taylor Blau
2024-05-23 16:38 ` [PATCH 1/8] midx-write.c: tolerate `--preferred-pack` without bitmaps Taylor Blau
2024-05-29 7:47 ` Patrick Steinhardt
2024-05-29 22:29 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 2/8] midx-write.c: reduce argument count for `get_sorted_entries()` Taylor Blau
2024-05-29 7:47 ` Patrick Steinhardt
2024-05-29 22:35 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 3/8] midx-write.c: pass `start_pack` to `get_sorted_entries()` Taylor Blau
2024-05-29 7:48 ` Patrick Steinhardt
2024-05-29 22:36 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 4/8] midx-write.c: extract `should_include_pack()` Taylor Blau
2024-05-29 7:48 ` Patrick Steinhardt
2024-05-29 22:40 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 5/8] midx-write.c: extract `fill_packs_from_midx()` Taylor Blau
2024-05-23 16:38 ` [PATCH 6/8] midx-write.c: support reading an existing MIDX with `packs_to_include` Taylor Blau
2024-05-29 7:48 ` Patrick Steinhardt [this message]
2024-05-29 22:46 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 7/8] midx: replace `get_midx_rev_filename()` with a generic helper Taylor Blau
2024-05-23 16:38 ` [PATCH 8/8] pack-bitmap.c: reimplement `midx_bitmap_filename()` with helper Taylor Blau
2024-05-29 22:55 ` [PATCH v2 0/8] midx-write: miscellaneous clean-ups for incremental MIDXs Taylor Blau
2024-05-29 22:55 ` [PATCH v2 1/8] midx-write.c: tolerate `--preferred-pack` without bitmaps Taylor Blau
2024-05-29 22:55 ` [PATCH v2 2/8] midx-write.c: reduce argument count for `get_sorted_entries()` Taylor Blau
2024-05-29 22:55 ` [PATCH v2 3/8] midx-write.c: pass `start_pack` to `compute_sorted_entries()` Taylor Blau
2024-05-30 6:59 ` Jeff King
2024-05-29 22:55 ` [PATCH v2 4/8] midx-write.c: extract `should_include_pack()` Taylor Blau
2024-05-29 22:55 ` [PATCH v2 5/8] midx-write.c: extract `fill_packs_from_midx()` Taylor Blau
2024-05-29 22:55 ` [PATCH v2 6/8] midx-write.c: support reading an existing MIDX with `packs_to_include` Taylor Blau
2024-05-30 7:05 ` Jeff King
2024-05-29 22:55 ` [PATCH v2 7/8] midx: replace `get_midx_rev_filename()` with a generic helper Taylor Blau
2024-05-30 7:10 ` Jeff King
2024-05-29 22:55 ` [PATCH v2 8/8] pack-bitmap.c: reimplement `midx_bitmap_filename()` with helper Taylor Blau
2024-05-30 7:14 ` [PATCH v2 0/8] midx-write: miscellaneous clean-ups for incremental MIDXs Jeff King
2024-05-30 13:59 ` Taylor Blau
2024-05-31 8:28 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZlbdxJmIBvgV_VIF@tanuki \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).