Hi,
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.
This patch series has been inspired by the discussion at [1]. I consider
it to be another step into the direction of replacing git-gc(1) and
allowing for more flexible maintenance strategies overall. Next steps
could be:
1. Enable the "reflog-expire" task by default when using the
"incremental" strategy. and then we might eventually switch over
the
2. Use "incremental" strategy when "features.experimental" is enabled.
3. Switch over the default strategy to "incremental" after a couple of
releases.
Thanks!
Patrick
[1]: <e650f4e4-e267-4f1f-bb3a-c71b1fe0b276@xxxxxx>
---
Patrick Steinhardt (6):
reflog: rename `cmd_reflog_expire_cb` to `reflog_expire_options`
builtin/reflog: stop storing default reflog expiry dates globally
builtin/reflog: stop storing per-reflog expiry dates globally
builtin/reflog: make functions regarding `reflog_expire_options` public
builtin/gc: split out function to expire reflog entries
builtin/maintenance: introduce "reflog-expire" task
Documentation/config/maintenance.adoc | 9 ++
Documentation/git-maintenance.adoc | 4 +
builtin/gc.c | 72 +++++++++++++---
builtin/reflog.c | 153 ++++------------------------------
reflog.c | 137 ++++++++++++++++++++++++++----
reflog.h | 35 +++++++-
t/t7900-maintenance.sh | 18 ++++
7 files changed, 263 insertions(+), 165 deletions(-)
---
base-commit: 5a526e5e18ddb9a7dfc5a2967d21d6154df64a4f
change-id: 20250226-pks-maintenance-reflog-expire-61c61410751a
