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

[Patrick Steinhardt <ps@pks.im>]

On Wed, Feb 26, 2025 at 06:54:48PM +0000, Ramsay Jones wrote:
> On 26/02/2025 18:40, Junio C Hamano wrote:
> > Ramsay Jones <ramsay@ramsayjones.plus.com> writes:
> > 
> >> Hmm, I don't know what you have in mind, but just as a data-point, I have
> >> never used, and have no inclination to use, git-maintenance. However, I do
> >> use git-gc extensively: at least once (times the number of repos fetched
> >> which have changes) per day, pretty much every day! :)
> > 
> > That makes two of us, but everybody knows that we are old fashioned ;-)
> 
> true, very true. :)

Well, it depends on what you mean by "use". In fact, both of you use it
implicitly assuming that you use a recent version of Git because that is
what Git nowadays spawns automatically: we don't use `git gc --auto`
anymore, but instead use `git maintenance run --auto`. It _does_ still
use git-gc(1) under the hood by default, but that is something we can
change going forward.

The opportunity here is to have a more fine-grained strategy to perform
maintenance, both when run explicitly but also when run automatically by
Git. git-maintenance(1) is written in a way that makes it significantly
more flexible overall, so we can iterate on how exactly it performs the
maintenance for the user. Different strategies may make sense in some
contexts, but not in others, and that is something we can account for
here.

It also allows us to bring newer features to the masses that have a
chance to improve performance or reduce the time spent maintaining
repositories for everyone: multi-pack indices, split commit graphs,
geometric repacking, incremental bitmaps.

While we could move them into git-gc(1), I think that this tool is just
not well-suited for such changes as it simply doesn't provide a good
foundation for tweakable behaviour.

Patrick