From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <ttaylorr@openai.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Jeff King <peff@peff.net>, Ted Nyman <tnyman@openai.com>
Subject: Re: [PATCH 1/2] maintenance: account for promisor pack geometry
Date: Mon, 10 Aug 2026 17:11:32 +0200 [thread overview]
Message-ID: <annqJGFJPviEyfEC@pks.im> (raw)
In-Reply-To: <a9de123b43efb58c53c99c71eb7e34f29e075071.1785902237.git.ttaylorr@openai.com>
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
next prev parent reply other threads:[~2026-08-10 15:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 3:57 [PATCH 0/2] maintenance: handle geometric repack tasks with promisor pack(s) Taylor Blau
2026-08-05 3:57 ` [PATCH 1/2] maintenance: account for promisor pack geometry Taylor Blau
2026-08-10 15:11 ` Patrick Steinhardt [this message]
2026-08-10 15:56 ` Taylor Blau
2026-08-11 10:01 ` Patrick Steinhardt
2026-08-11 15:49 ` Taylor Blau
2026-08-11 16:18 ` Patrick Steinhardt
2026-08-05 3:57 ` [PATCH 2/2] maintenance: trigger --auto for promisor rollups Taylor Blau
2026-08-10 15:11 ` Patrick Steinhardt
2026-08-10 15:56 ` Taylor Blau
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=annqJGFJPviEyfEC@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=tnyman@openai.com \
--cc=ttaylorr@openai.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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