git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Patrick Steinhardt <ps@pks.im>
Date
Oct 15, 2025, 12:14 UTC
Message-ID
<aO-QIn7KAVlBmfRq@pks.im>
In-Reply-To
<CAOLa=ZRdxm787nE4FSr2VUHDB+hW06Ggc6yUcKmeTKAb6B7YOA@mail.gmail.com>
On Wed, Oct 15, 2025 at 02:29:35AM -0700, Karthik Nayak wrote:
Show 56 quoted lines
> Karthik Nayak <karthik.188@gmail.com> writes:
> 
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> 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.
> >>
> >
> > I see what you mean.
> >
> >> 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
Previous: Karthik NayakNext: Junio C Hamano
Message 35 of 36 in “refs: add a '--required' flag to 'git refs optimize'”
  1. 0/9 refs: add a '--required' flag to 'git refs optimize'Karthik Nayak, Oct 10, 2025
  2. 1/9 refs: move to using the '.optimize' functionsKarthik Nayak, Oct 10, 2025
  3. Patrick SteinhardtOct 10, 2025
  4. Karthik NayakOct 13, 2025
  5. 2/9 refs: cleanup code around optimizationKarthik Nayak, Oct 10, 2025
  6. Patrick SteinhardtOct 10, 2025
  7. Karthik NayakOct 13, 2025
  8. 3/9 refs: rename 'pack_refs_opts' to 'optimize_refs_opts'Karthik Nayak, Oct 10, 2025
  9. Patrick SteinhardtOct 10, 2025
  10. Karthik NayakOct 13, 2025
  11. 4/9 t/pack-refs-tests: move the 'test_done' to calleesKarthik Nayak, Oct 10, 2025
  12. Patrick SteinhardtOct 10, 2025
  13. Karthik NayakOct 13, 2025
  14. 5/9 t/t0450: split whitespace consistency check per subcommandKarthik Nayak, Oct 10, 2025
  15. 6/9 reftable/stack: return stack segments directlyKarthik Nayak, Oct 10, 2025
  16. Patrick SteinhardtOct 10, 2025
  17. Karthik NayakOct 13, 2025
  18. Patrick SteinhardtOct 13, 2025
  19. 7/9 reftable/stack: add function to check if optimization is requiredKarthik Nayak, Oct 10, 2025
  20. Patrick SteinhardtOct 10, 2025
  21. Karthik NayakOct 13, 2025
  22. 8/9 refs: add a `optimize_required` field to `struct ref_storage_be`Karthik Nayak, Oct 10, 2025
  23. Patrick SteinhardtOct 10, 2025
  24. Karthik NayakOct 13, 2025
  25. 9/9 refs: add a '--required' flag to 'git refs optimize'Karthik Nayak, Oct 10, 2025
  26. Patrick SteinhardtOct 10, 2025
  27. Karthik NayakOct 13, 2025
  28. Junio C HamanoOct 13, 2025
  29. Junio C HamanoOct 13, 2025
  30. Karthik NayakOct 14, 2025
  31. Junio C HamanoOct 14, 2025
  32. Srivastava, NitinOct 15, 2025
  33. Karthik NayakOct 15, 2025
  34. Karthik NayakOct 15, 2025
  35. Patrick SteinhardtOct 15, 2025
  36. Junio C HamanoOct 15, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.