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@xxxxxxxxxxxxxxxxxxxx> 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
