> 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.

> Commit 9bc151850c (builtin/maintenance: introduce "geometric-repack"
> task, 2025-10-24) added an auto condition for the geometric-repack
> task. It runs the task when ordinary packs need to be combined or when
> the number of loose objects crosses the configured threshold.
> 
> Later on in commit dcc9c7ef47 (builtin/repack: handle promisor packs
> with geometric repacking, 2026-01-05), the geometric repack machinery
> started handling promisor packs separately, but did not correspondingly
> update the auto condition.
> 
> As a result, a repository can have promisor packs ready to combine
> while its non-promisor packs and loose object count require no work. In
> that case, `--auto` skips the task even though a geometric repack
> would combine at least two promisor packs.
> 
> Check `geometry.promisor_split` alongside `geometry.split`.

> diff --git a/builtin/gc.c b/builtin/gc.c
> index ed75c12c43..e9572940dc 100644
> --- a/builtin/gc.c
> +++ b/builtin/gc.c
> @@ -1649,7 +1649,7 @@ static int geometric_repack_auto_condition(struct gc_config *cfg UNUSED)
>  	 * When we'd merge at least two packs with one another we always
>  	 * perform the repack.
>  	 */
> -	if (geometry.split) {
> +	if (geometry.split || geometry.promisor_split) {
>  		ret = 1;
>  		goto out;
>  	}

> diff --git a/t/t5331-pack-objects-stdin.sh b/t/t5331-pack-objects-stdin.sh
> index c74b5861af..2a983e28ac 100755
> --- a/t/t5331-pack-objects-stdin.sh
> +++ b/t/t5331-pack-objects-stdin.sh
> @@ -368,7 +368,8 @@ test_expect_success '--stdin-packs does not perform backfill fetch' '
>  	git -C remote config set --local uploadpack.allowfilter 1 &&
>  	git -C remote config set --local uploadpack.allowanysha1inwant 1 &&
>  
> -	git clone --filter=tree:0 "file://$(pwd)/remote" client &&
> +	git -c maintenance.auto=false clone --filter=tree:0 \
> +		"file://$(pwd)/remote" client &&
>  	(
>  		cd client &&
>  		ls .git/objects/pack/*.promisor | sed "s|.*/||; s/\.promisor$/.pack/" >packs &&

> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
> index ba5b359e77..fb5f2d8902 100755
> --- a/t/t7900-maintenance.sh
> +++ b/t/t7900-maintenance.sh
> @@ -759,6 +759,29 @@ test_expect_success 'geometric repacking with --auto' '
>  	)
>  '
>  
> +test_expect_success 'geometric repacking with --auto handles promisor packs' '
> +	test_when_finished "rm -rf repo" &&
> +	git init repo &&
> +	(
> +		cd repo &&
> +		git config set maintenance.auto false &&
> +		git remote add promisor garbage &&
> +		git config set remote.promisor.promisor true &&
> +
> +		for n in $(test_seq 6)
> +		do
> +			test_commit $n || return 1
> +		done &&
> +
> +		pack_promisor 1 >/dev/null &&
> +		pack_promisor 1..2 >/dev/null &&
> +		pack_promisor 2..6 >/dev/null &&
> +		git prune-packed &&
> +
> +		test_geometric_repack_needed true auto=9000

> > 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.

> On Mon, Aug 10, 2026 at 05:11:32PM +0200, Patrick Steinhardt wrote:
> > > 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.
> 
> Right. I stumbled on this after a few colleagues had reported that their
> geometric maintenance task didn't seem to be doing anything. When
> looking into it, I found that they had many promisor packs, but the
> non-promisor packs were already in a geometric progression, and thus we
> did an all-into-one 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.
> 
> The change in this patch means that we will perform a geometric repack
> when doing so would result in a new geometrically-repacked series of
> promisor packs, in addition to non-promisor ones.
> 
> Is your concern that the non-promisor packs might be in a state where we
> should compact them into a single pack, but that the sequence of
> promisor packs would prevent us from doing so? In that case, we will
> perform a geometric repack on both sets of packs independently. If the
> non-promisor packs should be rolled up into a single pack (i.e.,
> "geometry.split == geometry.pack_nr"), then the geometric repack *will*
> produce a single pack, as if we had performed an all-into-one repack on
> the set of non-promisor packs.
> 
> So I am not sure that I understand your concern here, but please let me
> know if I am missing some aspect of it.

> > So I am not sure that I understand your concern here, but please let me
> > know if I am missing some aspect of it.
>
> The concern is that it's quite unlikely that both the geometric and
> non-geometric sequence will merge all packs together at the same point
> in time. Consequently, we'll never hit the case where we perform an
> all-into-one pack to prune unreachable objects, and that may cause us to
> never prune objects at all.
>
> So what I'm wondering is whether we should be a bit more clever about
> that and perform an all-into-one repack under a new condition, like for
> example when the objects we're about to repack exceed a certain
> percentage of the repository size.
>
> Hope that clarifies it a bit :)

> On Tue, Aug 11, 2026 at 12:01:23PM +0200, Patrick Steinhardt wrote:
> > > So I am not sure that I understand your concern here, but please let me
> > > know if I am missing some aspect of it.
> >
> > The concern is that it's quite unlikely that both the geometric and
> > non-geometric sequence will merge all packs together at the same point
> > in time. Consequently, we'll never hit the case where we perform an
> > all-into-one pack to prune unreachable objects, and that may cause us to
> > never prune objects at all.
> >
> > So what I'm wondering is whether we should be a bit more clever about
> > that and perform an all-into-one repack under a new condition, like for
> > example when the objects we're about to repack exceed a certain
> > percentage of the repository size.
> >
> > Hope that clarifies it a bit :)
> 
> Ah, I see what you're saying. We should still be OK here as the goal of
> geometric repacking is to converge both the promisor and non-promisor
> packs towards a single pack, at which point we would do an all-into-one
> repack.
> 
> If the two are perfectly out of phase, then this change would prevent us
> from running all-into-one maintenance. But that does not seem like a
> likely scenario, and the behavior here should be a strict improvement in
> the meantime otherwise.