git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 --]

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