Re: [PATCH 0/6] builtin/maintenance: introduce "reflog-expire" task
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Feb 28, 2025, 08:35 UTC
- Message-ID
- <Z8F1NDvWgx1S3eze@pks.im>
- In-Reply-To
- <xmqq8qpr9v9e.fsf@gitster.g>
On Thu, Feb 27, 2025 at 09:01:49AM -0800, Junio C Hamano wrote:
Show 29 quoted lines
> Patrick Steinhardt <ps@pks.im> writes: > > > 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. > > Or maybe leave breadcrumbs and invite others to help advance the > cause? If we know we have achieved consensus that it is a good > direction to go in, that is (we already saw a mention that indicates > that there are populations of us who do not care too much about > extending maintenance but are familiar with gc).
Oh, sure, I wouldn't mind at all if somebody else picked this up. The question to me is where to leave the breadcrumb, other than having it in this thread.
Patrick