From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Markus Gerstel <2025@uxp.de>,
Derrick Stolee <stolee@gmail.com>
Subject: Re: [PATCH 0/6] builtin/maintenance: introduce "reflog-expire" task
Date: Wed, 26 Feb 2025 17:23:10 -0800 [thread overview]
Message-ID: <xmqqikow9o5d.fsf@gitster.g> (raw)
In-Reply-To: <20250226-pks-maintenance-reflog-expire-v1-0-a1204a814952@pks.im> (Patrick Steinhardt's message of "Wed, 26 Feb 2025 16:24:25 +0100")
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.
next prev parent reply other threads:[~2025-02-27 1:23 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-26 15:24 [PATCH 0/6] builtin/maintenance: introduce "reflog-expire" task Patrick Steinhardt
2025-02-26 15:24 ` [PATCH 1/6] reflog: rename `cmd_reflog_expire_cb` to `reflog_expire_options` Patrick Steinhardt
2025-02-26 15:24 ` [PATCH 2/6] builtin/reflog: stop storing default reflog expiry dates globally Patrick Steinhardt
2025-03-04 23:23 ` Justin Tobler
2025-02-26 15:24 ` [PATCH 3/6] builtin/reflog: stop storing per-reflog " Patrick Steinhardt
2025-03-04 23:41 ` Justin Tobler
2025-03-06 10:37 ` Patrick Steinhardt
2025-03-06 23:17 ` Justin Tobler
2025-02-26 15:24 ` [PATCH 4/6] builtin/reflog: make functions regarding `reflog_expire_options` public Patrick Steinhardt
2025-02-26 15:24 ` [PATCH 5/6] builtin/gc: split out function to expire reflog entries Patrick Steinhardt
2025-02-26 15:24 ` [PATCH 6/6] builtin/maintenance: introduce "reflog-expire" task Patrick Steinhardt
2025-02-26 17:50 ` [PATCH 0/6] " Ramsay Jones
2025-02-26 18:40 ` Junio C Hamano
2025-02-26 18:54 ` Ramsay Jones
2025-02-27 9:10 ` Patrick Steinhardt
2025-02-27 1:23 ` Junio C Hamano [this message]
2025-02-27 9:22 ` Patrick Steinhardt
2025-02-27 17:01 ` Junio C Hamano
2025-02-28 8:35 ` Patrick Steinhardt
2025-04-08 6:22 ` [PATCH v2 " Patrick Steinhardt
2025-04-08 6:22 ` [PATCH v2 1/6] reflog: rename `cmd_reflog_expire_cb` to `reflog_expire_options` Patrick Steinhardt
2025-04-08 6:22 ` [PATCH v2 2/6] builtin/reflog: stop storing default reflog expiry dates globally Patrick Steinhardt
2025-04-08 6:22 ` [PATCH v2 3/6] builtin/reflog: stop storing per-reflog " Patrick Steinhardt
2025-04-08 6:22 ` [PATCH v2 4/6] builtin/reflog: make functions regarding `reflog_expire_options` public Patrick Steinhardt
2025-04-08 6:22 ` [PATCH v2 5/6] builtin/gc: split out function to expire reflog entries Patrick Steinhardt
2025-04-08 6:22 ` [PATCH v2 6/6] builtin/maintenance: introduce "reflog-expire" task Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqikow9o5d.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=2025@uxp.de \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=stolee@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).