{"thread":{"id":"66118","subject":"[PATCH 0/2] maintenance: handle geometric repack tasks with promisor pack(s)","startedAt":"2026-08-05T03:57:40Z","lastAt":"2026-08-11T16:18:19Z","messageCount":10,"participants":["Taylor Blau","Patrick Steinhardt"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"549634","messageId":"cover.1785902237.git.ttaylorr@openai.com","threadId":"66118","inReplyTo":null,"subject":"[PATCH 0/2] maintenance: handle geometric repack tasks with promisor pack(s)","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-08-05T03:57:32Z","receivedAt":"2026-08-05T03:57:40Z","isPatch":true,"body":"The geometric-repack maintenance task predates support for keeping\npromisor packs in their own geometric progression. After that support\nwas added in dcc9c7ef47 (builtin/repack: handle promisor packs with\ngeometric repacking, 2026-01-05), the maintenance task still made two\ndecisions from the ordinary-pack progression alone:\n\n - whether an explicit run should use `--geometric` or its\n all-into-one fallback; and\n\n - whether `--auto` sees enough work to run the task at all.\n\nThat can make partial clones rewrite more than necessary. If the\nordinary packs would all be rolled up, the task can choose the\nall-into-one path even when the promisor progression would leave a\nlarge pack alone. Likewise, an all-promisor repository can have a\npromisor rollup ready while `--auto` sees neither an ordinary split\nnor enough loose objects and skips the task.\n\nThe first patch makes the repack-mode choice consider both\nprogressions. It keeps the all-into-one fallback only when neither\nprogression leaves a pack above its split, so the fallback does not\nrewrite packs that geometric repack would have kept.\n\nThe second patch makes the `--auto` condition consider\n`geometry.promisor_split` alongside `geometry.split`. A non-zero split\non either side means that geometric repack can combine at least two\npacks.\n\nBoth tests build three promisor packs whose object counts cause the two\nsmaller packs to roll up while leaving the large pack intact. The\n`--auto` test uses a high loose-object threshold, so the promisor split\nis the only reason the task runs.\n\nThanks in advance for your review!\n\nTaylor Blau (2):\n maintenance: account for promisor pack geometry\n maintenance: trigger --auto for promisor rollups\n\n builtin/gc.c | 5 +--\n t/t5331-pack-objects-stdin.sh | 3 +-\n t/t7900-maintenance.sh | 68 +++++++++++++++++++++++++++++++++++\n 3 files changed, 73 insertions(+), 3 deletions(-)\n\n\nbase-commit: a97fcc37c2bc6340a8d7ce78dedf227aac4e9aa7\n-- \n2.55.0.483.gdc2fffc37c\n"},{"id":"549635","messageId":"a9de123b43efb58c53c99c71eb7e34f29e075071.1785902237.git.ttaylorr@openai.com","threadId":"66118","inReplyTo":"cover.1785902237.git.ttaylorr@openai.com","subject":"[PATCH 1/2] maintenance: account for promisor pack geometry","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-08-05T03:57:40Z","receivedAt":"2026-08-05T03:57:45Z","isPatch":true,"body":"Commit 9bc151850c (builtin/maintenance: introduce\n\"geometric-repack\" task, 2025-10-24) added a new maintenance task to\nperform either a geometric repack, or an all-into-one repack if the\ngeometric repack would itself produce a single pack.\n\nSome time later, commit dcc9c7ef47 (builtin/repack: handle promisor\npacks with geometric repacking, 2026-01-05) taught the geometric\nrepacking machinery to separate promisor packs from ordinary ones, but\ndid not update the maintenance task accordingly.\n\nAs a consequence, the geometric-repack maintenance task only considers\nthe non-promisor pack progression. It falls back to all-into-one\nwhenever a geometric repack would roll up all non-promisor packs into a\nsingle pack, even if the promisor progression would keep a large pack\nand roll up only smaller ones.\n\nCheck both progressions before choosing the repack mode. If either\nleaves a pack above its split, geometric repack still avoids rewriting\nthat pack, whereas the all-into-one fallback would rewrite it. Use the\nfallback only when neither progression leaves a pack behind. That\npreserves the reason for the fallback: let the all-into-one repack\nhandle unreachable objects when it is not rewriting more packs than the\ngeometric repack.\n\nSigned-off-by: Taylor Blau \n---\n builtin/gc.c | 3 ++-\n t/t7900-maintenance.sh | 45 ++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 47 insertions(+), 1 deletion(-)\n\ndiff --git a/builtin/gc.c b/builtin/gc.c\nindex 49c8474fad..ed75c12c43 100644\n--- a/builtin/gc.c\n+++ b/builtin/gc.c\n@@ -1593,7 +1593,8 @@ static int maintenance_task_geometric_repack(struct maintenance_run_opts *opts,\n \tchild.odb_to_close = the_repository->objects;\n \n \tstrvec_pushl(&child.args, \"repack\", \"-d\", \"-l\", NULL);\n-\tif (geometry.split < geometry.pack_nr)\n+\tif (geometry.split < geometry.pack_nr ||\n+\t geometry.promisor_split < geometry.promisor_pack_nr)\n \t\tstrvec_pushf(&child.args, \"--geometric=%d\",\n \t\t\t geometry.split_factor);\n \telse\ndiff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\nindex a8d691719d..ba5b359e77 100755\n--- a/t/t7900-maintenance.sh\n+++ b/t/t7900-maintenance.sh\n@@ -659,6 +659,51 @@ test_expect_success 'geometric repacking task' '\n \t)\n '\n \n+objdir=.git/objects\n+packdir=$objdir/pack\n+\n+pack_promisor () {\n+\tp=\"$(echo \"$@\" | git pack-objects --revs $packdir/pack)\" &&\n+\ttouch \"$packdir/pack-$p.promisor\" &&\n+\techo \"$p\"\n+}\n+\n+test_expect_success 'geometric repacking task handles promisor packs' '\n+\ttest_when_finished \"rm -rf repo\" &&\n+\tgit init repo &&\n+\t(\n+\t\tcd repo &&\n+\t\tgit config set maintenance.auto false &&\n+\t\tgit remote add promisor garbage &&\n+\t\tgit config set remote.promisor.promisor true &&\n+\n+\t\tfor n in $(test_seq 6)\n+\t\tdo\n+\t\t\ttest_commit $n || return 1\n+\t\tdone &&\n+\n+\t\tA=\"$(pack_promisor 1)\" &&\n+\t\tB=\"$(pack_promisor 1..2)\" &&\n+\t\tC=\"$(pack_promisor 2..6)\" &&\n+\t\tgit prune-packed &&\n+\n+\t\tls $packdir/pack-*.promisor | sort >promisors.before &&\n+\t\tGIT_TRACE2_EVENT=\"$(pwd)/trace2.txt\" \\\n+\t\t\tgit maintenance run --quiet --task=geometric-repack &&\n+\t\tls $packdir/pack-*.promisor | sort >promisors.after &&\n+\n+\t\ttest_subcommand git repack -d -l --geometric=2 \\\n+\t\t\t--quiet --write-midx expect &&\n+\t\tcomm -23 promisors.before promisors.after >actual &&\n+\n+\t\ttest_cmp expect actual\n+\t)\n+'\n+\n test_geometric_repack_needed () {\n \tNEEDED=\"$1\"\n \tGEOMETRIC_CONFIG=\"$2\" &&\n-- \n2.55.0.483.gdc2fffc37c\n\n"},{"id":"549636","messageId":"dc2fffc37cead551f8036c9ecab5e52a4cbee37b.1785902237.git.ttaylorr@openai.com","threadId":"66118","inReplyTo":"cover.1785902237.git.ttaylorr@openai.com","subject":"[PATCH 2/2] maintenance: trigger --auto for promisor rollups","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-08-05T03:57:46Z","receivedAt":"2026-08-05T03:57:52Z","isPatch":true,"body":"Commit 9bc151850c (builtin/maintenance: introduce \"geometric-repack\"\ntask, 2025-10-24) added an auto condition for the geometric-repack\ntask. It runs the task when ordinary packs need to be combined or when\nthe number of loose objects crosses the configured threshold.\n\nLater on in commit dcc9c7ef47 (builtin/repack: handle promisor packs\nwith geometric repacking, 2026-01-05), the geometric repack machinery\nstarted handling promisor packs separately, but did not correspondingly\nupdate the auto condition.\n\nAs a result, a repository can have promisor packs ready to combine\nwhile its non-promisor packs and loose object count require no work. In\nthat case, `--auto` skips the task even though a geometric repack\nwould combine at least two promisor packs.\n\nCheck `geometry.promisor_split` alongside `geometry.split`.\n\nThere is some fallout in t5331: the new condition makes a filtered\nclone eligible for auto-maintenance before the test inspects its\npromisor packs. Disable auto-maintenance in that fixture so it\ncontinues to test `--stdin-packs`, not the maintenance task.\n\nSigned-off-by: Taylor Blau \n---\n builtin/gc.c | 2 +-\n t/t5331-pack-objects-stdin.sh | 3 ++-\n t/t7900-maintenance.sh | 23 +++++++++++++++++++++++\n 3 files changed, 26 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/gc.c b/builtin/gc.c\nindex ed75c12c43..e9572940dc 100644\n--- a/builtin/gc.c\n+++ b/builtin/gc.c\n@@ -1649,7 +1649,7 @@ static int geometric_repack_auto_condition(struct gc_config *cfg UNUSED)\n \t * When we'd merge at least two packs with one another we always\n \t * perform the repack.\n \t */\n-\tif (geometry.split) {\n+\tif (geometry.split || geometry.promisor_split) {\n \t\tret = 1;\n \t\tgoto out;\n \t}\ndiff --git a/t/t5331-pack-objects-stdin.sh b/t/t5331-pack-objects-stdin.sh\nindex c74b5861af..2a983e28ac 100755\n--- a/t/t5331-pack-objects-stdin.sh\n+++ b/t/t5331-pack-objects-stdin.sh\n@@ -368,7 +368,8 @@ test_expect_success '--stdin-packs does not perform backfill fetch' '\n \tgit -C remote config set --local uploadpack.allowfilter 1 &&\n \tgit -C remote config set --local uploadpack.allowanysha1inwant 1 &&\n \n-\tgit clone --filter=tree:0 \"file://$(pwd)/remote\" client &&\n+\tgit -c maintenance.auto=false clone --filter=tree:0 \\\n+\t\t\"file://$(pwd)/remote\" client &&\n \t(\n \t\tcd client &&\n \t\tls .git/objects/pack/*.promisor | sed \"s|.*/||; s/\\.promisor$/.pack/\" >packs &&\ndiff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\nindex ba5b359e77..fb5f2d8902 100755\n--- a/t/t7900-maintenance.sh\n+++ b/t/t7900-maintenance.sh\n@@ -759,6 +759,29 @@ test_expect_success 'geometric repacking with --auto' '\n \t)\n '\n \n+test_expect_success 'geometric repacking with --auto handles promisor packs' '\n+\ttest_when_finished \"rm -rf repo\" &&\n+\tgit init repo &&\n+\t(\n+\t\tcd repo &&\n+\t\tgit config set maintenance.auto false &&\n+\t\tgit remote add promisor garbage &&\n+\t\tgit config set remote.promisor.promisor true &&\n+\n+\t\tfor n in $(test_seq 6)\n+\t\tdo\n+\t\t\ttest_commit $n || return 1\n+\t\tdone &&\n+\n+\t\tpack_promisor 1 >/dev/null &&\n+\t\tpack_promisor 1..2 >/dev/null &&\n+\t\tpack_promisor 2..6 >/dev/null &&\n+\t\tgit prune-packed &&\n+\n+\t\ttest_geometric_repack_needed true auto=9000\n+\t)\n+'\n+\n test_expect_success 'geometric repacking honors configured split factor' '\n \ttest_when_finished \"rm -rf repo\" &&\n \tgit init repo &&\n-- \n2.55.0.483.gdc2fffc37c\n"},{"id":"550193","messageId":"annqJGFJPviEyfEC@pks.im","threadId":"66118","inReplyTo":"a9de123b43efb58c53c99c71eb7e34f29e075071.1785902237.git.ttaylorr@openai.com","subject":"Re: [PATCH 1/2] maintenance: account for promisor pack geometry","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-10T15:11:32Z","receivedAt":"2026-08-10T15:11:40Z","isPatch":true,"body":"On Tue, Aug 04, 2026 at 08:57:40PM -0700, Taylor Blau wrote:\n> Commit 9bc151850c (builtin/maintenance: introduce\n> \"geometric-repack\" task, 2025-10-24) added a new maintenance task to\n> perform either a geometric repack, or an all-into-one repack if the\n> geometric repack would itself produce a single pack.\n> \n> Some time later, commit dcc9c7ef47 (builtin/repack: handle promisor\n> packs with geometric repacking, 2026-01-05) taught the geometric\n> repacking machinery to separate promisor packs from ordinary ones, but\n> did not update the maintenance task accordingly.\n> \n> As a consequence, the geometric-repack maintenance task only considers\n> the non-promisor pack progression. It falls back to all-into-one\n> whenever a geometric repack would roll up all non-promisor packs into a\n> single pack, even if the promisor progression would keep a large pack\n> and roll up only smaller ones.\n> \n> Check both progressions before choosing the repack mode. If either\n> leaves a pack above its split, geometric repack still avoids rewriting\n> that pack, whereas the all-into-one fallback would rewrite it. Use the\n> fallback only when neither progression leaves a pack behind. That\n> preserves the reason for the fallback: let the all-into-one repack\n> handle unreachable objects when it is not rewriting more packs than the\n> geometric repack.\n\nOkay. The consequence of the status quo could be that we perform an\nall-into-one repack more frequent than really desired because the set of\nnon-promised packs is small, and thus even writing a small set of new\nobjects could cause a full repack.\n\nThis might create the reverse situation though, where we don't perform\nthe all-into-one repack at all anymore. We could come up with a clever\nsolution here, like for example considering both sequences together and\nrepacking when we cross a certain combined threshold. But I'm not sure\nit's worth it for now, and we can still evolve the strategy as needed.\n\nPatrick\n"},{"id":"550194","messageId":"annqKRGoh4-S91VE@pks.im","threadId":"66118","inReplyTo":"dc2fffc37cead551f8036c9ecab5e52a4cbee37b.1785902237.git.ttaylorr@openai.com","subject":"Re: [PATCH 2/2] maintenance: trigger --auto for promisor rollups","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-10T15:11:37Z","receivedAt":"2026-08-10T15:11:42Z","isPatch":true,"body":"On Tue, Aug 04, 2026 at 08:57:46PM -0700, Taylor Blau wrote:\n> Commit 9bc151850c (builtin/maintenance: introduce \"geometric-repack\"\n> task, 2025-10-24) added an auto condition for the geometric-repack\n> task. It runs the task when ordinary packs need to be combined or when\n> the number of loose objects crosses the configured threshold.\n> \n> Later on in commit dcc9c7ef47 (builtin/repack: handle promisor packs\n> with geometric repacking, 2026-01-05), the geometric repack machinery\n> started handling promisor packs separately, but did not correspondingly\n> update the auto condition.\n> \n> As a result, a repository can have promisor packs ready to combine\n> while its non-promisor packs and loose object count require no work. In\n> that case, `--auto` skips the task even though a geometric repack\n> would combine at least two promisor packs.\n> \n> Check `geometry.promisor_split` alongside `geometry.split`.\n\nYeah, this is a more obviously correct thing to do compared to the\npreceding patch.\n\n> diff --git a/builtin/gc.c b/builtin/gc.c\n> index ed75c12c43..e9572940dc 100644\n> --- a/builtin/gc.c\n> +++ b/builtin/gc.c\n> @@ -1649,7 +1649,7 @@ static int geometric_repack_auto_condition(struct gc_config *cfg UNUSED)\n> \t * When we'd merge at least two packs with one another we always\n> \t * perform the repack.\n> \t */\n> -\tif (geometry.split) {\n> +\tif (geometry.split || geometry.promisor_split) {\n> \t\tret = 1;\n> \t\tgoto out;\n> \t}\n\nThis looks obviously correct.\n\n> diff --git a/t/t5331-pack-objects-stdin.sh b/t/t5331-pack-objects-stdin.sh\n> index c74b5861af..2a983e28ac 100755\n> --- a/t/t5331-pack-objects-stdin.sh\n> +++ b/t/t5331-pack-objects-stdin.sh\n> @@ -368,7 +368,8 @@ test_expect_success '--stdin-packs does not perform backfill fetch' '\n> \tgit -C remote config set --local uploadpack.allowfilter 1 &&\n> \tgit -C remote config set --local uploadpack.allowanysha1inwant 1 &&\n> \n> -\tgit clone --filter=tree:0 \"file://$(pwd)/remote\" client &&\n> +\tgit -c maintenance.auto=false clone --filter=tree:0 \\\n> +\t\t\"file://$(pwd)/remote\" client &&\n> \t(\n> \t\tcd client &&\n> \t\tls .git/objects/pack/*.promisor | sed \"s|.*/||; s/\\.promisor$/.pack/\" >packs &&\n\nCurious that git-clone(1) already spawns maintenance, but with \"tree:0\"\nwe may end up fetching multiple promisor packs from the remote as we\ndiscover more trees to backfill. So this makes sense.\n\n> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh\n> index ba5b359e77..fb5f2d8902 100755\n> --- a/t/t7900-maintenance.sh\n> +++ b/t/t7900-maintenance.sh\n> @@ -759,6 +759,29 @@ test_expect_success 'geometric repacking with --auto' '\n> \t)\n> '\n> \n> +test_expect_success 'geometric repacking with --auto handles promisor packs' '\n> +\ttest_when_finished \"rm -rf repo\" &&\n> +\tgit init repo &&\n> +\t(\n> +\t\tcd repo &&\n> +\t\tgit config set maintenance.auto false &&\n> +\t\tgit remote add promisor garbage &&\n> +\t\tgit config set remote.promisor.promisor true &&\n> +\n> +\t\tfor n in $(test_seq 6)\n> +\t\tdo\n> +\t\t\ttest_commit $n || return 1\n> +\t\tdone &&\n> +\n> +\t\tpack_promisor 1 >/dev/null &&\n> +\t\tpack_promisor 1..2 >/dev/null &&\n> +\t\tpack_promisor 2..6 >/dev/null &&\n> +\t\tgit prune-packed &&\n> +\n> +\t\ttest_geometric_repack_needed true auto=9000\n\nThe auto-value here doesn't matter at all, as we shouldn't have any\nloose objects in the first place and really only want to trigger\nmaintenance because of the promisors. Makes sense.\n\nThanks!\n\nPatrick\n"},{"id":"550199","messageId":"ann0nnSGfSJ7y7YK@com-79390","threadId":"66118","inReplyTo":"annqJGFJPviEyfEC@pks.im","subject":"Re: [PATCH 1/2] maintenance: account for promisor pack geometry","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-08-10T15:56:14Z","receivedAt":"2026-08-10T15:56:27Z","isPatch":true,"body":"On Mon, Aug 10, 2026 at 05:11:32PM +0200, Patrick Steinhardt wrote:\n> > Check both progressions before choosing the repack mode. If either\n> > leaves a pack above its split, geometric repack still avoids rewriting\n> > that pack, whereas the all-into-one fallback would rewrite it. Use the\n> > fallback only when neither progression leaves a pack behind. That\n> > preserves the reason for the fallback: let the all-into-one repack\n> > handle unreachable objects when it is not rewriting more packs than the\n> > geometric repack.\n>\n> Okay. The consequence of the status quo could be that we perform an\n> all-into-one repack more frequent than really desired because the set of\n> non-promised packs is small, and thus even writing a small set of new\n> objects could cause a full repack.\n\nRight. I stumbled on this after a few colleagues had reported that their\ngeometric maintenance task didn't seem to be doing anything. When\nlooking into it, I found that they had many promisor packs, but the\nnon-promisor packs were already in a geometric progression, and thus we\ndid an all-into-one repack.\n\n> This might create the reverse situation though, where we don't perform\n> the all-into-one repack at all anymore. We could come up with a clever\n> solution here, like for example considering both sequences together and\n> repacking when we cross a certain combined threshold. But I'm not sure\n> it's worth it for now, and we can still evolve the strategy as needed.\n\nThe change in this patch means that we will perform a geometric repack\nwhen doing so would result in a new geometrically-repacked series of\npromisor packs, in addition to non-promisor ones.\n\nIs your concern that the non-promisor packs might be in a state where we\nshould compact them into a single pack, but that the sequence of\npromisor packs would prevent us from doing so? In that case, we will\nperform a geometric repack on both sets of packs independently. If the\nnon-promisor packs should be rolled up into a single pack (i.e.,\n\"geometry.split == geometry.pack_nr\"), then the geometric repack *will*\nproduce a single pack, as if we had performed an all-into-one repack on\nthe set of non-promisor packs.\n\nSo I am not sure that I understand your concern here, but please let me\nknow if I am missing some aspect of it.\n\nThanks,\nTaylor\n"},{"id":"550200","messageId":"ann0wdIUxB0O6Scx@com-79390","threadId":"66118","inReplyTo":"annqKRGoh4-S91VE@pks.im","subject":"Re: [PATCH 2/2] maintenance: trigger --auto for promisor rollups","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-08-10T15:56:49Z","receivedAt":"2026-08-10T15:56:56Z","isPatch":true,"body":"On Mon, Aug 10, 2026 at 05:11:37PM +0200, Patrick Steinhardt wrote:\n> Thanks!\n>\n> Patrick\n\nThanks for the review!\n\nThanks,\nTaylor\n"},{"id":"550275","messageId":"anry8wAbkxNfVgfh@pks.im","threadId":"66118","inReplyTo":"ann0nnSGfSJ7y7YK@com-79390","subject":"Re: [PATCH 1/2] maintenance: account for promisor pack geometry","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-11T10:01:23Z","receivedAt":"2026-08-11T10:01:32Z","isPatch":true,"body":"On Mon, Aug 10, 2026 at 10:56:14AM -0500, Taylor Blau wrote:\n> On Mon, Aug 10, 2026 at 05:11:32PM +0200, Patrick Steinhardt wrote:\n> > > Check both progressions before choosing the repack mode. If either\n> > > leaves a pack above its split, geometric repack still avoids rewriting\n> > > that pack, whereas the all-into-one fallback would rewrite it. Use the\n> > > fallback only when neither progression leaves a pack behind. That\n> > > preserves the reason for the fallback: let the all-into-one repack\n> > > handle unreachable objects when it is not rewriting more packs than the\n> > > geometric repack.\n> >\n> > Okay. The consequence of the status quo could be that we perform an\n> > all-into-one repack more frequent than really desired because the set of\n> > non-promised packs is small, and thus even writing a small set of new\n> > objects could cause a full repack.\n> \n> Right. I stumbled on this after a few colleagues had reported that their\n> geometric maintenance task didn't seem to be doing anything. When\n> looking into it, I found that they had many promisor packs, but the\n> non-promisor packs were already in a geometric progression, and thus we\n> did an all-into-one repack.\n> \n> > This might create the reverse situation though, where we don't perform\n> > the all-into-one repack at all anymore. We could come up with a clever\n> > solution here, like for example considering both sequences together and\n> > repacking when we cross a certain combined threshold. But I'm not sure\n> > it's worth it for now, and we can still evolve the strategy as needed.\n> \n> The change in this patch means that we will perform a geometric repack\n> when doing so would result in a new geometrically-repacked series of\n> promisor packs, in addition to non-promisor ones.\n> \n> Is your concern that the non-promisor packs might be in a state where we\n> should compact them into a single pack, but that the sequence of\n> promisor packs would prevent us from doing so? In that case, we will\n> perform a geometric repack on both sets of packs independently. If the\n> non-promisor packs should be rolled up into a single pack (i.e.,\n> \"geometry.split == geometry.pack_nr\"), then the geometric repack *will*\n> produce a single pack, as if we had performed an all-into-one repack on\n> the set of non-promisor packs.\n> \n> So I am not sure that I understand your concern here, but please let me\n> know if I am missing some aspect of it.\n\nThe concern is that it's quite unlikely that both the geometric and\nnon-geometric sequence will merge all packs together at the same point\nin time. Consequently, we'll never hit the case where we perform an\nall-into-one pack to prune unreachable objects, and that may cause us to\nnever prune objects at all.\n\nSo what I'm wondering is whether we should be a bit more clever about\nthat and perform an all-into-one repack under a new condition, like for\nexample when the objects we're about to repack exceed a certain\npercentage of the repository size.\n\nHope that clarifies it a bit :)\n\nThanks!\n\nPatrick\n"},{"id":"550291","messageId":"antEnTVfHFEGQQZ_@com-79390","threadId":"66118","inReplyTo":"anry8wAbkxNfVgfh@pks.im","subject":"Re: [PATCH 1/2] maintenance: account for promisor pack geometry","fromName":"Taylor Blau","fromEmail":"ttaylorr@openai.com","sentAt":"2026-08-11T15:49:49Z","receivedAt":"2026-08-11T15:49:59Z","isPatch":true,"body":"On Tue, Aug 11, 2026 at 12:01:23PM +0200, Patrick Steinhardt wrote:\n> > So I am not sure that I understand your concern here, but please let me\n> > know if I am missing some aspect of it.\n>\n> The concern is that it's quite unlikely that both the geometric and\n> non-geometric sequence will merge all packs together at the same point\n> in time. Consequently, we'll never hit the case where we perform an\n> all-into-one pack to prune unreachable objects, and that may cause us to\n> never prune objects at all.\n>\n> So what I'm wondering is whether we should be a bit more clever about\n> that and perform an all-into-one repack under a new condition, like for\n> example when the objects we're about to repack exceed a certain\n> percentage of the repository size.\n>\n> Hope that clarifies it a bit :)\n\nAh, I see what you're saying. We should still be OK here as the goal of\ngeometric repacking is to converge both the promisor and non-promisor\npacks towards a single pack, at which point we would do an all-into-one\nrepack.\n\nIf the two are perfectly out of phase, then this change would prevent us\nfrom running all-into-one maintenance. But that does not seem like a\nlikely scenario, and the behavior here should be a strict improvement in\nthe meantime otherwise.\n\nThanks,\nTaylor\n"},{"id":"550292","messageId":"antLRFfKMtSLaqdy@pks.im","threadId":"66118","inReplyTo":"antEnTVfHFEGQQZ_@com-79390","subject":"Re: [PATCH 1/2] maintenance: account for promisor pack geometry","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2026-08-11T16:18:12Z","receivedAt":"2026-08-11T16:18:19Z","isPatch":true,"body":"On Tue, Aug 11, 2026 at 10:49:49AM -0500, Taylor Blau wrote:\n> On Tue, Aug 11, 2026 at 12:01:23PM +0200, Patrick Steinhardt wrote:\n> > > So I am not sure that I understand your concern here, but please let me\n> > > know if I am missing some aspect of it.\n> >\n> > The concern is that it's quite unlikely that both the geometric and\n> > non-geometric sequence will merge all packs together at the same point\n> > in time. Consequently, we'll never hit the case where we perform an\n> > all-into-one pack to prune unreachable objects, and that may cause us to\n> > never prune objects at all.\n> >\n> > So what I'm wondering is whether we should be a bit more clever about\n> > that and perform an all-into-one repack under a new condition, like for\n> > example when the objects we're about to repack exceed a certain\n> > percentage of the repository size.\n> >\n> > Hope that clarifies it a bit :)\n> \n> Ah, I see what you're saying. We should still be OK here as the goal of\n> geometric repacking is to converge both the promisor and non-promisor\n> packs towards a single pack, at which point we would do an all-into-one\n> repack.\n> \n> If the two are perfectly out of phase, then this change would prevent us\n> from running all-into-one maintenance. But that does not seem like a\n> likely scenario, and the behavior here should be a strict improvement in\n> the meantime otherwise.\n\nYeah, I tend to agree. It's heuristics anyway, and from my point of view\nit's something that we can iterate on going forward.\n\nThanks!\n\nPatrick\n"}]}