From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: git@vger.kernel.org, ps@pks.im, jltobler@gmail.com
Subject: Re: [PATCH v2 2/5] reftable/stack: add function to check if optimization is required
Date: Tue, 04 Nov 2025 12:26:27 -0800 [thread overview]
Message-ID: <xmqqcy5xpmrw.fsf@gitster.g> (raw)
In-Reply-To: <20251104-562-add-sub-command-to-check-if-maintenance-is-needed-v2-2-303462a9e4ed@gmail.com> (Karthik Nayak's message of "Tue, 04 Nov 2025 09:43:57 +0100")
Karthik Nayak <karthik.188@gmail.com> writes:
> The reftable backend performs auto-compaction as part of its regular
> flow, which is required to keep the number of tables part of a stack at
> bay. This allows it to stay optimized.
Sounds very sensible.
> Compaction can also be triggered voluntarily by the user via the 'git
> pack-refs' or the 'git refs optimize' command. However, currently there
> is no way for the user to check if optimization is required without
> actually performing it.
Sounds very sensible goal.
But where is the existing logic to decide when it needs to
auto-compact, performed as part of its regular flow?
After reading "the reftable machinery already decides when it needs
to compact and does so" plus "but the logic to decide is not made
available to users", I would have expected for this patch to extract
such an existing logic or otherwise make it available to new callers
so that things like "gc --auto" can call it, but the diffstat shows
mostly additions, which does not give readers any confidence in the
new function that answers "do we need compaction?". It would give
_an_ answer, but there is no clue if the answer it gives is the same
answer as the existing logic that decides when to compact as part of
the regular operation.
I am puzzled.
> +int reftable_stack_compaction_required(struct reftable_stack *st,
> + bool use_heuristics,
> + bool *required)
> +{
> + struct segment seg;
> + int err = 0;
> +
> + if (st->merged->tables_len < 2) {
> + *required = false;
> + return 0;
> + }
> +
> + if (!use_heuristics) {
> + *required = true;
> + return 0;
> + }
> +
> + err = stack_segments_for_compaction(st, &seg);
> + if (err)
> + return err;
> +
> + *required = segment_size(&seg) > 0;
> + return 0;
> +}
Specifically, where is the above logic come from? Is it duplicating
an existing logic but that code is hard to separate out into this
helper?
> int reftable_stack_auto_compact(struct reftable_stack *st)
> {
> struct segment seg;
> diff --git a/t/unit-tests/u-reftable-stack.c b/t/unit-tests/u-reftable-stack.c
> index a8b91812e8..b8110cdeee 100644
> --- a/t/unit-tests/u-reftable-stack.c
> +++ b/t/unit-tests/u-reftable-stack.c
> @@ -1067,6 +1067,7 @@ void test_reftable_stack__add_performs_auto_compaction(void)
> .value_type = REFTABLE_REF_SYMREF,
> .value.symref = (char *) "master",
> };
> + bool required = false;
> char buf[128];
>
> /*
> @@ -1087,10 +1088,17 @@ void test_reftable_stack__add_performs_auto_compaction(void)
> * auto compaction is disabled. When enabled, we should merge
> * all tables in the stack.
> */
> - if (i != n)
> + cl_assert_equal_i(reftable_stack_compaction_required(st, true, &required), 0);
> + if (i != n) {
> cl_assert_equal_i(st->merged->tables_len, i + 1);
> - else
> + if (i < 1)
> + cl_assert_equal_b(required, false);
> + else
> + cl_assert_equal_b(required, true);
> + } else {
> cl_assert_equal_i(st->merged->tables_len, 1);
> + cl_assert_equal_b(required, false);
> + }
> }
>
> reftable_stack_destroy(st);
next prev parent reply other threads:[~2025-11-04 20:26 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 14:22 [PATCH 0/5] maintenance: add an 'is-needed' subcommand Karthik Nayak
2025-10-31 14:22 ` [PATCH 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-10-31 16:22 ` Justin Tobler
2025-11-03 15:05 ` Karthik Nayak
2025-11-03 18:03 ` Justin Tobler
2025-10-31 14:22 ` [PATCH 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-10-31 17:02 ` Justin Tobler
2025-10-31 18:17 ` Junio C Hamano
2025-11-03 16:20 ` Karthik Nayak
2025-11-03 15:51 ` Karthik Nayak
2025-11-03 17:59 ` Justin Tobler
2025-11-03 14:00 ` Patrick Steinhardt
2025-11-03 16:35 ` Karthik Nayak
2025-10-31 14:22 ` [PATCH 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-10-31 14:22 ` [PATCH 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-03 14:00 ` Patrick Steinhardt
2025-11-03 17:04 ` Karthik Nayak
2025-10-31 14:22 ` [PATCH 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-03 14:00 ` Patrick Steinhardt
2025-11-03 17:18 ` Karthik Nayak
2025-11-04 5:54 ` Patrick Steinhardt
2025-11-04 8:28 ` Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 0/5] maintenance: add an " Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-04 20:26 ` Junio C Hamano [this message]
2025-11-05 14:11 ` Karthik Nayak
2025-11-05 18:10 ` Junio C Hamano
2025-11-06 8:18 ` Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-04 8:43 ` [PATCH v2 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-04 8:44 ` [PATCH v2 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-04 15:43 ` [PATCH v2 0/5] maintenance: add an " Junio C Hamano
2025-11-05 14:00 ` Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 " Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-06 18:18 ` Junio C Hamano
2025-11-07 6:06 ` Patrick Steinhardt
2025-11-06 8:22 ` [PATCH v3 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-06 11:58 ` Patrick Steinhardt
2025-11-06 13:04 ` Karthik Nayak
2025-11-06 15:24 ` Junio C Hamano
2025-11-07 15:58 ` Karthik Nayak
2025-11-07 16:41 ` Junio C Hamano
2025-11-07 15:58 ` Karthik Nayak
2025-11-06 8:22 ` [PATCH v3 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-06 12:02 ` Patrick Steinhardt
2025-11-06 13:07 ` Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 0/5] maintenance: add an " Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 1/5] reftable/stack: return stack segments directly Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 2/5] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 3/5] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 4/5] maintenance: add checking logic in `pack_refs_condition()` Karthik Nayak
2025-11-08 21:51 ` [PATCH v4 5/5] maintenance: add 'is-needed' subcommand Karthik Nayak
2025-11-10 6:46 ` [PATCH v4 0/5] maintenance: add an " 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=xmqqcy5xpmrw.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=karthik.188@gmail.com \
--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 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).