git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Wed, 05 Nov 2025 10:10:47 -0800	[thread overview]
Message-ID: <xmqqms50l594.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZRD_zNCnGf3ibU=X04vC8WjxzRVAyg+OwPr1Hf12kSGgA@mail.gmail.com> (Karthik Nayak's message of "Wed, 5 Nov 2025 09:11:53 -0500")

Karthik Nayak <karthik.188@gmail.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> 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?
>>
>
> Good question.
>
> Most of this logic is already part of 'reftable_stack_auto_compact()'.
> We also have another similar function 'reftable_stack_compact_all()'.
> The former is used for compaction based on heuristics and the latter is
> for compacting all tables into one. In the refs subsystem usage of
> heuristics is denoted by the usage of the 'REFS_OPTIMIZE_AUTO' flag.
>
> The function we're introducing allows users to explicitly mention if
> they want to use heuristics or not. This allows us to differentiate
> between the two modes. The result of which is that this uses intertwined
> logic of the two existing functions. Hence we can't extract any code out.
>
> I'll add this information in the commit message.

You mean you already have two duplicate implementations whose
definition of "when should we compact?" can drift apart over time
(worse, they may already be subtly different), and you are adding
yet another one?

Instead of describing such an insanity in the commit message, can we
refactor to have a single central logic that is used from three
places?

Thanks.

  reply	other threads:[~2025-11-05 18:10 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
2025-11-05 14:11       ` Karthik Nayak
2025-11-05 18:10         ` Junio C Hamano [this message]
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=xmqqms50l594.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).