Git development
 help / color / mirror / Atom feed
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

  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