Re: [PATCH 0/6] builtin/maintenance: introduce "reflog-expire" task

[Patrick Steinhardt <ps@pks.im>]

On Wed, Feb 26, 2025 at 05:23:10PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> 
> > this patch series introduces a new "reflog-expire" task to
> > git-maintenance(1). This task is designed to plug a gap when the "gc"
> > task is disabled, as there is no way to expire reflog entries in that
> > case.
> 
> I think in the longer run, "maintenance" users should be able to
> treat the single ball of wax "gc" task as a mere short-hand to
> invoke a set of often used maintenance tasks, and we would want to
> break down the component tasks grouped in it and make them
> independently available.  This is a good step along that journey.
> 
> Are there other things that the "gc" task covers that are not
> available elsewhere?  "git gc --help" suggests there are things
> related to pruning (unused?) worktrees and stale rerere database
> entries.

These are more gaps indeed. I'm happy to work on them once this patch
series has landed. I don't know about any other gaps.

> Another thing, how much control do we want to cede to the end users
> the choice of tasks and order of running them?  When you are
> expiring stale reflog entries and repacking the object database to
> discard unreachable objects, it would only make sense to do them in
> the order I just said.  We could leave it up to the end users, but
> that may be doing disservice to them.

This is a good question. From my perspective, there are three classes of
users here:

  - Those that don't care and don't have special needs. This class of
    users is unlikely to tweak things anyway.

  - Those that aren't deeply familiar with how Git works, but who do
    have special needs e.g. because they have huge repositories. This
    class of users may need to tweak configuration, but we should give
    them an _easy_ way to do so. Configuring individual tasks ain't that
    from my perspective.

  - Power users that are deeply familiar with how Git works. This class
    of users may even want to tweak the order in which specific tasks
    run.

"maintenance.strategy" exists to cater to the second class of users and
allows them to configure the high-level strategy used to maintain repos.
I don't know whether it's honored by `git maintenance run`, but I think
it is (and if it's not it should be).

That to me means that the configuration for individual tasks for power
users can be as flexible as possible, including configuring the order in
which tasks are run.

Patrick