From: Taylor Blau <ttaylorr@openai.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, Jeff King <peff@peff.net>,
Patrick Steinhardt <ps@pks.im>, Ted Nyman <tnyman@openai.com>
Subject: [PATCH 0/2] maintenance: handle geometric repack tasks with promisor pack(s)
Date: Tue, 4 Aug 2026 20:57:32 -0700 [thread overview]
Message-ID: <cover.1785902237.git.ttaylorr@openai.com> (raw)
The geometric-repack maintenance task predates support for keeping
promisor packs in their own geometric progression. After that support
was added in dcc9c7ef47 (builtin/repack: handle promisor packs with
geometric repacking, 2026-01-05), the maintenance task still made two
decisions from the ordinary-pack progression alone:
- whether an explicit run should use `--geometric` or its
all-into-one fallback; and
- whether `--auto` sees enough work to run the task at all.
That can make partial clones rewrite more than necessary. If the
ordinary packs would all be rolled up, the task can choose the
all-into-one path even when the promisor progression would leave a
large pack alone. Likewise, an all-promisor repository can have a
promisor rollup ready while `--auto` sees neither an ordinary split
nor enough loose objects and skips the task.
The first patch makes the repack-mode choice consider both
progressions. It keeps the all-into-one fallback only when neither
progression leaves a pack above its split, so the fallback does not
rewrite packs that geometric repack would have kept.
The second patch makes the `--auto` condition consider
`geometry.promisor_split` alongside `geometry.split`. A non-zero split
on either side means that geometric repack can combine at least two
packs.
Both tests build three promisor packs whose object counts cause the two
smaller packs to roll up while leaving the large pack intact. The
`--auto` test uses a high loose-object threshold, so the promisor split
is the only reason the task runs.
Thanks in advance for your review!
Taylor Blau (2):
maintenance: account for promisor pack geometry
maintenance: trigger --auto for promisor rollups
builtin/gc.c | 5 +--
t/t5331-pack-objects-stdin.sh | 3 +-
t/t7900-maintenance.sh | 68 +++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+), 3 deletions(-)
base-commit: a97fcc37c2bc6340a8d7ce78dedf227aac4e9aa7
--
2.55.0.483.gdc2fffc37c
next reply other threads:[~2026-08-05 3:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-05 3:57 Taylor Blau [this message]
2026-08-05 3:57 ` [PATCH 1/2] maintenance: account for promisor pack geometry Taylor Blau
2026-08-05 3:57 ` [PATCH 2/2] maintenance: trigger --auto for promisor rollups 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=cover.1785902237.git.ttaylorr@openai.com \
--to=ttaylorr@openai.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
--cc=tnyman@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