All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org,  Jeff King <peff@peff.net>,
	 Elijah Newren <newren@gmail.com>,
	 Patrick Steinhardt <ps@pks.im>
Subject: Re: [RFC PATCH 04/10] repack: teach MIDX retention about geometric rollups
Date: Fri, 26 Jun 2026 14:28:18 -0700	[thread overview]
Message-ID: <xmqqwlvl56vh.fsf@gitster.g> (raw)
In-Reply-To: <ad76f06fc7ed304af97c73a5931e1ebc5f2d3895.1782500507.git.me@ttaylorr.com> (Taylor Blau's message of "Fri, 26 Jun 2026 15:02:23 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> +static int pack_geometry_contains_pack(struct packed_git **packs,
> +				       uint32_t packs_nr,
> +				       const char *base)
> +{
> +	struct strbuf buf = STRBUF_INIT;
> +	uint32_t i;
> +
> +	for (i = 0; i < packs_nr; i++) {
> +		strbuf_reset(&buf);
> +		strbuf_addstr(&buf, pack_basename(packs[i]));
> +		strbuf_strip_suffix(&buf, ".pack");
> +
> +		if (!strcmp(buf.buf, base)) {
> +			strbuf_release(&buf);
> +			return 1;
> +		}
> +	}
> +
> +	strbuf_release(&buf);
> +	return 0;
> +}

It feels slightly inefficient to repeatedly strbuf_reset(),
strbuf_addstr(), and strbuf_strip_suffix() in the loop.  I do not
know if my understanding of what existing_packs_retain_midx_packs()
passes down in buf.buf as base is correct or not, but if so,
wouldn't it equivalent to

	for (uint32_t i = 0; i < packs_nr; i++) {
                const char *pack_name = pack_basename(packs[i]);
                const char *suffix;

                if (skip_prefix(pack_name, base, &suffix) &&
                    !strcmp(suffix, ".pack"))
                        return 1;
	}

perhaps?

Starting from "/path/to/objects/pack/pack-deadbeef.pack", you take
the basename of it to have "pack-deadbeef.pack" in buf, strip out
the ".pack" suffix to get "pack-deadbeef" in buf and then compare it
with the base.

Instead, pack_name in the rewitten one becomes the basename of the
packfile path, i.e., "pack-deadbeef.pack", then we see if it begins
with base and take the remainder in suffix, and finally we check if
that remaining suffix is ".pack".

Which should be equivalent.

> + * freshly-written pack supersedes them. When doing a geometric repack,
> + * packs below the split are rewritten into the new MIDX tip and should
> + * remain eligible for deletion.
>   */
> -void existing_packs_retain_midx_packs(struct existing_packs *existing)
> +void existing_packs_retain_midx_packs(struct existing_packs *existing,
> +				      const struct pack_geometry *geometry)
>  {
>  	struct string_list_item *item;
>  	struct strbuf buf = STRBUF_INIT;
> @@ -315,6 +351,9 @@ void existing_packs_retain_midx_packs(struct existing_packs *existing)
>  		strbuf_strip_suffix(&buf, ".pack");
>  		strbuf_strip_suffix(&buf, ".idx");

Not a fault of this patch, but it makes the hairs on the back of my
head tingle to see that a bogus input like "pack-foobar.idx.pack"
happily is taken, while "pack-foobar.pack.idx", an equally bogus
input, is not.

> +		if (pack_geometry_contains_rollup(geometry, buf.buf))
> +			continue;

  reply	other threads:[~2026-06-26 21:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26 19:02 [RFC PATCH 00/10] repack: combine '--geometric' and '--cruft' Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 01/10] repack: unconditionally exclude non-kept packs Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 02/10] repack: extract `locate_existing_pack()` helper Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 03/10] repack: mark geometric progression of packs as retained Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 04/10] repack: teach MIDX retention about geometric rollups Taylor Blau
2026-06-26 21:28   ` Junio C Hamano [this message]
2026-06-27  0:43     ` Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 05/10] repack: delete geometric packs via existing_packs Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 06/10] repack-geometry: drop unused redundant-pack removal Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 07/10] pack-objects: extract `stdin_packs_add_all_pack_entries()` Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 08/10] pack-objects: introduce '--stdin-packs=follow-reachable' Taylor Blau
2026-06-26 21:39   ` Junio C Hamano
2026-06-27  0:41     ` Taylor Blau
2026-06-27  2:09       ` Junio C Hamano
2026-06-27  2:26         ` Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 09/10] pack-objects: support '--refs-snapshot' with 'follow-reachable' Taylor Blau
2026-06-26 19:02 ` [RFC PATCH 10/10] repack: support combining '--geometric' with '--cruft' Taylor Blau

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=xmqqwlvl56vh.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=newren@gmail.com \
    --cc=peff@peff.net \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.