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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 27, 2025, 01:23 UTC
Message-ID: <xmqqikow9o5d.fsf@gitster.g>
In-Reply-To: <20250226-pks-maintenance-reflog-expire-v1-0-a1204a814952@pks.im>

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.

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.