maintenance: handle geometric repack tasks with promisor pack(s)

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.

t/t5331-pack-objects-stdin.sh +0 -0

index c74b5861af..2a983e28ac 100755

t/t7900-maintenance.sh +10 -0

index ba5b359e77..fb5f2d8902 100755
@@ -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)

Quoted 7 lines

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.

Thanks!

Patrick

Quoted 8 lines · Patrick Steinhardt

Quoted 7 lines

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.

Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 2 lines

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 :)

Quoted 9 lines · Patrick Steinhardt

Quoted 2 lines

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.

Quoted 6 lines

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.