git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Patrick Steinhardt <ps@pks.im>
Date
Feb 27, 2025, 09:10 UTC
Message-ID
<Z8AsGdPqDVXpqkhR@pks.im>
In-Reply-To
<5ecea6cc-0702-47a7-91de-14aa06757d27@ramsayjones.plus.com>
On Wed, Feb 26, 2025 at 06:54:48PM +0000, Ramsay Jones wrote:
Show 11 quoted lines
> 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
Previous: Ramsay JonesNext: Junio C Hamano
Message 15 of 26 in “builtin/maintenance: introduce "reflog-expire" task”
  1. 0/6 builtin/maintenance: introduce "reflog-expire" taskPatrick Steinhardt, Feb 26, 2025
  2. 1/6 reflog: rename `cmd_reflog_expire_cb` to `reflog_expire_options`Patrick Steinhardt, Feb 26, 2025
  3. 2/6 builtin/reflog: stop storing default reflog expiry dates globallyPatrick Steinhardt, Feb 26, 2025
  4. Justin ToblerMar 4, 2025
  5. 3/6 builtin/reflog: stop storing per-reflog expiry dates globallyPatrick Steinhardt, Feb 26, 2025
  6. Justin ToblerMar 4, 2025
  7. Patrick SteinhardtMar 6, 2025
  8. Justin ToblerMar 6, 2025
  9. 4/6 builtin/reflog: make functions regarding `reflog_expire_options` publicPatrick Steinhardt, Feb 26, 2025
  10. 5/6 builtin/gc: split out function to expire reflog entriesPatrick Steinhardt, Feb 26, 2025
  11. 6/6 builtin/maintenance: introduce "reflog-expire" taskPatrick Steinhardt, Feb 26, 2025
  12. Ramsay JonesFeb 26, 2025
  13. Junio C HamanoFeb 26, 2025
  14. Ramsay JonesFeb 26, 2025
  15. Patrick SteinhardtFeb 27, 2025
  16. Junio C HamanoFeb 27, 2025
  17. Patrick SteinhardtFeb 27, 2025
  18. Junio C HamanoFeb 27, 2025
  19. Patrick SteinhardtFeb 28, 2025
  20. 0/6 builtin/maintenance: introduce "reflog-expire" taskPatrick Steinhardt, Apr 8, 2025
  21. 2/6 builtin/reflog: stop storing default reflog expiry dates globallyPatrick Steinhardt, Apr 8, 2025
  22. 1/6 reflog: rename `cmd_reflog_expire_cb` to `reflog_expire_options`Patrick Steinhardt, Apr 8, 2025
  23. 3/6 builtin/reflog: stop storing per-reflog expiry dates globallyPatrick Steinhardt, Apr 8, 2025
  24. 4/6 builtin/reflog: make functions regarding `reflog_expire_options` publicPatrick Steinhardt, Apr 8, 2025
  25. 5/6 builtin/gc: split out function to expire reflog entriesPatrick Steinhardt, Apr 8, 2025
  26. 6/6 builtin/maintenance: introduce "reflog-expire" taskPatrick Steinhardt, Apr 8, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.