Re: [PATCH 1/2] maintenance: account for promisor pack geometry

On Tue, Aug 04, 2026 at 08:57:40PM -0700, Taylor Blau wrote:
> Commit 9bc151850c (builtin/maintenance: introduce
> "geometric-repack" task, 2025-10-24) added a new maintenance task to
> perform either a geometric repack, or an all-into-one repack if the
> geometric repack would itself produce a single pack.
> 
> Some time later, commit dcc9c7ef47 (builtin/repack: handle promisor
> packs with geometric repacking, 2026-01-05) taught the geometric
> repacking machinery to separate promisor packs from ordinary ones, but
> did not update the maintenance task accordingly.
> 
> As a consequence, the geometric-repack maintenance task only considers
> the non-promisor pack progression. It falls back to all-into-one
> whenever a geometric repack would roll up all non-promisor packs into a
> single pack, even if the promisor progression would keep a large pack
> and roll up only smaller ones.
> 
> Check both progressions before choosing the repack mode. If either
> leaves a pack above its split, geometric repack still avoids rewriting
> that pack, whereas the all-into-one fallback would rewrite it. Use the
> fallback only when neither progression leaves a pack behind. That
> preserves the reason for the fallback: let the all-into-one repack
> handle unreachable objects when it is not rewriting more packs than the
> geometric repack.

Okay. The consequence of the status quo could be that we perform an
all-into-one repack more frequent than really desired because the set of
non-promised packs is small, and thus even writing a small set of new
objects could cause a full repack.

This might create the reverse situation though, where we don't perform
the all-into-one repack at all anymore. We could come up with a clever
solution here, like for example considering both sequences together and
repacking when we cross a certain combined threshold. But I'm not sure
it's worth it for now, and we can still evolve the strategy as needed.

Patrick