All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Karthik Nayak <karthik.188@gmail.com>
Cc: Patrick Steinhardt <ps@pks.im>,  git@vger.kernel.org
Subject: Re: [PATCH 9/9] refs: add a '--required' flag to 'git refs optimize'
Date: Tue, 14 Oct 2025 10:46:43 -0700	[thread overview]
Message-ID: <xmqqldldxtoc.fsf@gitster.g> (raw)
In-Reply-To: <CAOLa=ZTRG=x5PofmSSfHhJ3Lig2NjhU8buVWAXU=aKom2PDsDg@mail.gmail.com> (Karthik Nayak's message of "Tue, 14 Oct 2025 11:08:56 -0400")

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

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Perhaps "--check-" followed by a word specific to what we are trying
>>> to achieve (e.g., if we are trying to see if auto-compaction is
>>> necessary, "--check-for-auto" "check for auto compaction")?  I
>>> dunno.
>>
>> After reading what you did in the previou step, I am reasonably sure
>> "required" is a wrong word to use, with or without other words like
>> "check".  Semantically it is similar to the should_pack_refs() check
>> that we use for pack-refs even before "optimize" came.  We expect it
>> to answer this question cheaply: are we better off if we repacked,
>> or can we go on without repacking for now?  It is not about "are we
>> performing so poorly that we MUST optimize now?"
>
> I agree '--required' isn't the best name, and like we discussed
> '--dry-run' wouldn't be either since that would imply that the work is
> being done but not persisted.
>
> I was leaning towards '--check', which is simple. But It might be nicer
> to be verbose here and simply add something like '--is-worthwhile'.
>
> Being verbose here is okay, since it will only be used sparingly and
> specifically by those who require such a use case.

Nah, "worthwhile" is relative and it would be less meaningful
without expressing for what goal we are judging how it is worthwhile
to do.

Choosing a phrase around "check" is better, I would think.



  reply	other threads:[~2025-10-14 17:46 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-10 10:27 [PATCH 0/9] refs: add a '--required' flag to 'git refs optimize' Karthik Nayak
2025-10-10 10:27 ` [PATCH 1/9] refs: move to using the '.optimize' functions Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:18     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 2/9] refs: cleanup code around optimization Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:22     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 3/9] refs: rename 'pack_refs_opts' to 'optimize_refs_opts' Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:52     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 4/9] t/pack-refs-tests: move the 'test_done' to callees Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  8:54     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 5/9] t/t0450: split whitespace consistency check per subcommand Karthik Nayak
2025-10-10 10:27 ` [PATCH 6/9] reftable/stack: return stack segments directly Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  9:01     ` Karthik Nayak
2025-10-13 11:10       ` Patrick Steinhardt
2025-10-10 10:27 ` [PATCH 7/9] reftable/stack: add function to check if optimization is required Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  9:04     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 8/9] refs: add a `optimize_required` field to `struct ref_storage_be` Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13  9:46     ` Karthik Nayak
2025-10-10 10:27 ` [PATCH 9/9] refs: add a '--required' flag to 'git refs optimize' Karthik Nayak
2025-10-10 11:22   ` Patrick Steinhardt
2025-10-13 12:37     ` Karthik Nayak
2025-10-13 13:40     ` Junio C Hamano
2025-10-13 14:37       ` Junio C Hamano
2025-10-14 15:08         ` Karthik Nayak
2025-10-14 17:46           ` Junio C Hamano [this message]
2025-10-15  7:50             ` Srivastava, Nitin
2025-10-15  8:19             ` Karthik Nayak
2025-10-15  9:29               ` Karthik Nayak
2025-10-15 12:14                 ` Patrick Steinhardt
2025-10-15 20:17                   ` Junio C Hamano

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=xmqqldldxtoc.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --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 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.