Thread (5 messages) 5 messages, 4 authors, 2025-10-15

Re: [PATCH 9/9] refs: add a '--required' flag to 'git refs optimize'

From: Patrick Steinhardt <hidden>
Date: 2025-10-15 12:14:37

On Wed, Oct 15, 2025 at 02:29:35AM -0700, Karthik Nayak wrote:
Karthik Nayak [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] writes:
quoted
Karthik Nayak [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] writes:
quoted
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.
I see what you mean.
quoted
Choosing a phrase around "check" is better, I would think.
How about simply `--check`. Since the flag can be used with other
existing flags, it would make more sense to do

  git refs optimize --all --auto --check
  git refs optimize --check
  git refs optimize --all --check

I will send in a new version around this and we can discuss further on
top of that!
After speaking to Patrick today about this and his work on 'git
maintenance', we realized we can actually broaden the scope. We could
implement something like 'git maintenance needed'. This would check on a
whole if repository maintenance is needed for refs and objects.
Yup. The idea here is that git-maintenance(1) is already split up into
different tasks, one of which is the "pack-refs" task. And each of these
tasks already has a callback to verify whether or not we need to execute
the task.

So if we build on top of that mechanism we can easily broaden the scope
of this patch series to:

  - Check whether maintenance is needed for any of the enabled tasks.

  - Check whether maintenance is needed for a single task.

  - Check whether maintenance is needed given a specific maintenance
    strategy.

Another benefit is that it's a bit easier to put a verb into a proper
subcommand of git-maintenance(1) instead of having to add a verb-ish
flag to git-pack-refs(1). `git maintenance is-needed` feels way more
natural to me at least compared to `git refs optimize --check`.

Thanks!

Patrick
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help