From: Junio C Hamano <gitster@pobox•com>
To: Derrick Stolee <stolee@gmail•com>
Cc: Patrick Steinhardt <ps@pks•im>, git@vger•kernel.org
Subject: Re: [PATCH v3 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1)
Date: Fri, 02 May 2025 14:07:28 -0700 [thread overview]
Message-ID: <xmqqo6wau3fz.fsf@gitster.g> (raw)
In-Reply-To: <d5307e82-8e45-4a2a-a8cc-03f84c2d5670@gmail.com> (Derrick Stolee's message of "Fri, 2 May 2025 10:57:33 -0400")
Derrick Stolee <stolee@gmail•com> writes:
> On 5/2/2025 4:43 AM, Patrick Steinhardt wrote:
>
>> Changes in v3:
>> - Simplify the heuristic for "rerere-gc" so that we only count the
>> number of directory entries in ".git/rr-cache", without considering
>> staleness.
>
> The range-diff was harder to read than just re-reviewing patch 7, but I
> think this v3 is ready to go.
I still do not think "configurable 'rerere gc' basing the decision
on the number of existing rerere entries" adds negative value to the
system. If there is truly more than N active rerere entries
currently in your repository with your workflow, such a
configuration essentially decides to run 'rerere gc' every time (and
without pruning enough entries to make the next 'rerere gc'
unnecessary), and never otherwise. It is not like pruning unneeded
loose object files and packing the rest into a packfile, where
running it once (even if it resulted in miniscule packfile due to
misidentification) would remove all the loose object files, which
makes 'repack' unneeded for some time until we accumulate more of
them. After 'rerere gc', you still will have rerere entries kept.
Until we can implement a meaningful automation (which may require
changing the way rerere entries are stored on disk to help us
cheaply tell if there truly are excessive number of no longer
relevant rerere entries; code that we can readily borrow from
"rerere gc" is enough, as I said), I do not think we should add
extra code to make such a useless decision. Instead, I would prefer
to see a single "do we or do we not run `rerere gc`?" Boolean, until
that happens.
Other than that, I think the series is a good addition to the
system. Giving finer grained control is great, and 'git maintenance'
is a much better framework than 'git gc' to do so.
Thanks, all.
next prev parent reply other threads:[~2025-05-02 21:07 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-25 7:29 [PATCH 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Patrick Steinhardt
2025-04-25 7:29 ` [PATCH 1/7] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-04-25 7:29 ` [PATCH 2/7] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-04-25 7:29 ` [PATCH 3/7] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-04-25 7:29 ` [PATCH 4/7] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-04-25 7:29 ` [PATCH 5/7] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-04-29 20:02 ` Derrick Stolee
2025-04-30 7:08 ` Patrick Steinhardt
2025-04-25 7:29 ` [PATCH 6/7] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-04-25 7:29 ` [PATCH 7/7] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-04-29 20:02 ` [PATCH 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Derrick Stolee
2025-04-30 7:08 ` Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 0/8] " Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 1/8] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 2/8] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 3/8] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 4/8] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 5/8] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 6/8] rerere: provide function to collect stale entries Patrick Steinhardt
2025-04-30 16:58 ` Junio C Hamano
2025-05-02 8:07 ` Patrick Steinhardt
2025-05-02 16:35 ` Junio C Hamano
2025-05-05 7:22 ` Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 7/8] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-04-30 10:25 ` [PATCH v2 8/8] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-04-30 10:37 ` [PATCH v2 0/8] builtin/maintenance: implement missing tasks compared to git-gc(1) Derrick Stolee
2025-05-02 8:43 ` [PATCH v3 0/7] " Patrick Steinhardt
2025-05-02 8:43 ` [PATCH v3 1/7] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-05-02 8:43 ` [PATCH v3 2/7] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-05-02 8:44 ` [PATCH v3 3/7] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-05-02 8:44 ` [PATCH v3 4/7] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-05-05 8:42 ` Eric Sunshine
2025-05-07 7:06 ` Patrick Steinhardt
2025-05-02 8:44 ` [PATCH v3 5/7] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-05-05 8:59 ` Eric Sunshine
2025-05-07 7:06 ` Patrick Steinhardt
2025-05-02 8:44 ` [PATCH v3 6/7] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-05-02 8:44 ` [PATCH v3 7/7] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-05-02 14:57 ` [PATCH v3 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Derrick Stolee
2025-05-02 21:07 ` Junio C Hamano [this message]
2025-05-05 7:32 ` Patrick Steinhardt
2025-05-05 8:51 ` [PATCH v4 " Patrick Steinhardt
2025-05-05 8:51 ` [PATCH v4 1/7] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-05-05 8:51 ` [PATCH v4 2/7] builtin/gc: remove global variables where it trivial to do Patrick Steinhardt
2025-05-06 7:44 ` Christian Couder
2025-05-07 7:06 ` Patrick Steinhardt
2025-05-05 8:51 ` [PATCH v4 3/7] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-05-06 7:50 ` Christian Couder
2025-05-07 7:06 ` Patrick Steinhardt
2025-05-05 8:51 ` [PATCH v4 4/7] worktree: expose function to retrieve worktree names Patrick Steinhardt
2025-05-06 8:20 ` Christian Couder
2025-05-06 16:08 ` Eric Sunshine
2025-05-05 8:51 ` [PATCH v4 5/7] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-05-06 7:40 ` Christian Couder
2025-05-07 7:06 ` Patrick Steinhardt
2025-05-05 8:51 ` [PATCH v4 6/7] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-05-06 8:39 ` Christian Couder
2025-05-05 8:51 ` [PATCH v4 7/7] builtin/maintenance: introduce "rerere-gc" task Patrick Steinhardt
2025-05-06 9:05 ` [PATCH v4 0/7] builtin/maintenance: implement missing tasks compared to git-gc(1) Christian Couder
2025-05-07 7:21 ` [PATCH v5 0/6] " Patrick Steinhardt
2025-05-07 7:21 ` [PATCH v5 1/6] builtin/gc: fix indentation of `cmd_gc()` parameters Patrick Steinhardt
2025-05-07 7:21 ` [PATCH v5 2/6] builtin/gc: remove global variables where it is trivial to do Patrick Steinhardt
2025-05-07 7:21 ` [PATCH v5 3/6] builtin/gc: move pruning of worktrees into a separate function Patrick Steinhardt
2025-05-07 7:21 ` [PATCH v5 4/6] builtin/maintenance: introduce "worktree-prune" task Patrick Steinhardt
2025-05-07 7:21 ` [PATCH v5 5/6] builtin/gc: move rerere garbage collection into separate function Patrick Steinhardt
2025-05-07 7:21 ` [PATCH v5 6/6] builtin/maintenance: introduce "rerere-gc" 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=xmqqo6wau3fz.fsf@gitster.g \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=ps@pks$(echo .)im \
--cc=stolee@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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