From 09505b11153a20e1c6c572d41db778171dd19cbc Mon Sep 17 00:00:00 2001 From: Patrick Steinhardt Date: Tue, 24 Feb 2026 09:45:45 +0100 Subject: [PATCH 1/8] t: fix races caused by background maintenance MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Many Git commands spawn git-maintenance(1) to optimize the repository in the background. By default, performing the maintenance is for most of the part asynchronous: we fork the executable and then continue with the rest of our business logic. This is working as expected for our users, but this behaviour is somewhat problematic for our test suite as this is inherently racy. We have many tests that verify the on-disk state of repositories, and those tests may easily race with our background maintenance. In a similar fashion, we may end up with processes that "leak" out of a current test case. Until now this tends to not be much of a problem. Our maintenance uses git-gc(1) by default, which knows to bail out in case there aren't either too many packfiles or too many loose objects. So even if other data structures would need to be optimized, we won't do so unless the object database also needs optimizations. This is about to change though, as a subsequent commit will switch to the "geometric" maintenance strategy as a default. The consequence is that we will run required optimizations even if the object database is well-optimized. And this uncovers races between our test suite and background maintenance all over the place. Disabling maintenance outright in our test suite is not really an option, as it would result in significant divergence from the "real world" and reduce our test coverage. But we've got an alternative up our sleeves: we can ensure that garbage collection runs synchronously by overriding the "maintenance.autoDetach" configuration. Of course that also diverges from the real world, as we now stop testing that background maintenance interacts in a benign way with normal Git commands. But on the other hand this ensures that the maintenance itself does not for example lead to data loss in a more reproducible way. Another concern is that this would make execution of the test suite much slower. But a quick benchmark on my machine demonstrates that this does not seem to be the case: Benchmark 1: meson test (revision = HEAD~) Time (mean ± σ): 131.182 s ± 1.293 s [User: 853.737 s, System: 1160.479 s] Range (min … max): 130.001 s … 132.563 s 3 runs Benchmark 2: meson test (revision = HEAD) Time (mean ± σ): 129.554 s ± 0.507 s [User: 849.040 s, System: 1152.664 s] Range (min … max): 129.000 s … 129.994 s 3 runs Summary meson test (revision = HEAD) ran 1.01 ± 0.01 times faster than meson test (revision = HEAD~) Funny enough, it even seems as if this speeds up test execution ever so slightly, but that may just as well be noise. Introduce a new `GIT_TEST_MAINT_AUTO_DETACH` environment variable that allows us to override the auto-detach behaviour and set that variable in our tests. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- run-command.c | 2 +- t/t5616-partial-clone.sh | 6 +++--- t/t7900-maintenance.sh | 3 +++ t/test-lib.sh | 4 ++++ 4 files changed, 11 insertions(+), 4 deletions(-) diff --git a/run-command.c b/run-command.c index e3e02475cc..438a290d30 100644 --- a/run-command.c +++ b/run-command.c @@ -1828,7 +1828,7 @@ int prepare_auto_maintenance(int quiet, struct child_process *maint) */ if (repo_config_get_bool(the_repository, "maintenance.autodetach", &auto_detach) && repo_config_get_bool(the_repository, "gc.autodetach", &auto_detach)) - auto_detach = 1; + auto_detach = git_env_bool("GIT_TEST_MAINT_AUTO_DETACH", true); maint->git_cmd = 1; maint->close_object_store = 1; diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-clone.sh index 1e354e057f..d62760eb92 100755 --- a/t/t5616-partial-clone.sh +++ b/t/t5616-partial-clone.sh @@ -229,7 +229,7 @@ test_expect_success 'fetch --refetch triggers repacking' ' GIT_TRACE2_EVENT="$PWD/trace1.event" \ git -C pc1 fetch --refetch origin && - test_subcommand git maintenance run --auto --no-quiet --detach Date: Tue, 24 Feb 2026 09:45:46 +0100 Subject: [PATCH 2/8] t: disable maintenance where we verify object database structure We have a couple of tests that explicitly verify the structure of the object database. Naturally, this structure is dependent on whether or not we run repository maintenance: if it decides to optimize the object database the expected structure is likely to not materialize. Explicitly disable auto-maintenance in such tests so that we are not dependent on decisions made by our maintenance. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- t/t0081-find-pack.sh | 1 + t/t5316-pack-delta-depth.sh | 1 + t/t5319-multi-pack-index.sh | 1 + t/t5326-multi-pack-bitmaps.sh | 3 ++- t/t5327-multi-pack-bitmaps-rev.sh | 3 ++- t/t5331-pack-objects-stdin.sh | 2 ++ t/t5332-multi-pack-reuse.sh | 1 + t/t5334-incremental-multi-pack-index.sh | 1 + t/t5500-fetch-pack.sh | 3 ++- t/t5616-partial-clone.sh | 1 + t/t7700-repack.sh | 3 +++ 11 files changed, 17 insertions(+), 3 deletions(-) diff --git a/t/t0081-find-pack.sh b/t/t0081-find-pack.sh index 5a628bf735..26f017422d 100755 --- a/t/t0081-find-pack.sh +++ b/t/t0081-find-pack.sh @@ -68,6 +68,7 @@ test_expect_success 'add more packfiles' ' ' test_expect_success 'add more commits (as loose objects)' ' + test_config maintenance.auto false && test_commit six && test_commit seven && diff --git a/t/t5316-pack-delta-depth.sh b/t/t5316-pack-delta-depth.sh index 03dfb7a61e..8a067a45cb 100755 --- a/t/t5316-pack-delta-depth.sh +++ b/t/t5316-pack-delta-depth.sh @@ -48,6 +48,7 @@ test_description='pack-objects breaks long cross-pack delta chains' # repeatedly-modified file to generate the delta chain). test_expect_success 'create series of packs' ' + test_config maintenance.auto false && test-tool genrandom foo 4096 >content && prev= && for i in $(test_seq 1 10) diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh index faae98c7e7..7672d599d4 100755 --- a/t/t5319-multi-pack-index.sh +++ b/t/t5319-multi-pack-index.sh @@ -1315,6 +1315,7 @@ test_expect_success 'bitmapped packs are stored via the BTMP chunk' ' git init repo && ( cd repo && + git config set maintenance.auto false && for i in 1 2 3 4 5 do diff --git a/t/t5326-multi-pack-bitmaps.sh b/t/t5326-multi-pack-bitmaps.sh index 892aeb09e4..62bd973d92 100755 --- a/t/t5326-multi-pack-bitmaps.sh +++ b/t/t5326-multi-pack-bitmaps.sh @@ -93,7 +93,8 @@ test_midx_bitmap_cases () { test_expect_success 'setup test_repository' ' rm -rf * .git && git init && - git config pack.writeBitmapLookupTable '"$writeLookupTable"' + git config pack.writeBitmapLookupTable '"$writeLookupTable"' && + git config maintenance.auto false ' midx_bitmap_core diff --git a/t/t5327-multi-pack-bitmaps-rev.sh b/t/t5327-multi-pack-bitmaps-rev.sh index 9cac03a94b..cfa12de2a8 100755 --- a/t/t5327-multi-pack-bitmaps-rev.sh +++ b/t/t5327-multi-pack-bitmaps-rev.sh @@ -30,7 +30,8 @@ test_midx_bitmap_rev () { test_expect_success 'setup bitmap config' ' rm -rf * .git && git init && - git config pack.writeBitmapLookupTable '"$writeLookupTable"' + git config pack.writeBitmapLookupTable '"$writeLookupTable"' && + git config maintenance.auto false ' midx_bitmap_core rev diff --git a/t/t5331-pack-objects-stdin.sh b/t/t5331-pack-objects-stdin.sh index cd949025b9..b03f6be164 100755 --- a/t/t5331-pack-objects-stdin.sh +++ b/t/t5331-pack-objects-stdin.sh @@ -14,6 +14,7 @@ packed_objects () { test_expect_success 'setup for --stdin-packs tests' ' git init stdin-packs && + git -C stdin-packs config set maintenance.auto false && ( cd stdin-packs && @@ -255,6 +256,7 @@ test_expect_success '--stdin-packs=follow walks into unknown packs' ' git init repo && ( cd repo && + git config set maintenance.auto false && for c in A B C D do diff --git a/t/t5332-multi-pack-reuse.sh b/t/t5332-multi-pack-reuse.sh index 395d09444c..881ce668e1 100755 --- a/t/t5332-multi-pack-reuse.sh +++ b/t/t5332-multi-pack-reuse.sh @@ -59,6 +59,7 @@ test_pack_objects_reused () { test_expect_success 'preferred pack is reused for single-pack reuse' ' test_config pack.allowPackReuse single && + git config set maintenance.auto false && for i in A B do diff --git a/t/t5334-incremental-multi-pack-index.sh b/t/t5334-incremental-multi-pack-index.sh index d30d7253d6..99c7d44d8e 100755 --- a/t/t5334-incremental-multi-pack-index.sh +++ b/t/t5334-incremental-multi-pack-index.sh @@ -15,6 +15,7 @@ midx_chain=$midxdir/multi-pack-index-chain test_expect_success 'convert non-incremental MIDX to incremental' ' test_commit base && + git config set maintenance.auto false && git repack -ad && git multi-pack-index write && diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh index 4bb56c167a..0c88d04d0a 100755 --- a/t/t5500-fetch-pack.sh +++ b/t/t5500-fetch-pack.sh @@ -154,7 +154,8 @@ test_expect_success 'clone shallow depth 1 with fsck' ' ' test_expect_success 'clone shallow' ' - git clone --no-single-branch --depth 2 "file://$(pwd)/." shallow + git clone --no-single-branch --depth 2 "file://$(pwd)/." shallow && + git -C shallow config set maintenance.auto false ' test_expect_success 'clone shallow depth count' ' diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-clone.sh index d62760eb92..1c2805acca 100755 --- a/t/t5616-partial-clone.sh +++ b/t/t5616-partial-clone.sh @@ -585,6 +585,7 @@ test_expect_success 'verify fetch downloads only one pack when updating refs' ' git clone --filter=blob:none "file://$(pwd)/srv.bare" pack-test && ls pack-test/.git/objects/pack/*pack >pack-list && test_line_count = 2 pack-list && + test_config -C pack-test maintenance.auto false && for i in A B C do test_commit -C src $i && diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh index 73b78bdd88..acc2589f21 100755 --- a/t/t7700-repack.sh +++ b/t/t7700-repack.sh @@ -217,6 +217,7 @@ test_expect_success 'repack --keep-pack' ' cd keep-pack && # avoid producing different packs due to delta/base choices git config pack.window 0 && + git config maintenance.auto false && P1=$(commit_and_pack 1) && P2=$(commit_and_pack 2) && P3=$(commit_and_pack 3) && @@ -260,6 +261,7 @@ test_expect_success 'repacking fails when missing .pack actually means missing o # Avoid producing different packs due to delta/base choices git config pack.window 0 && + git config maintenance.auto false && P1=$(commit_and_pack 1) && P2=$(commit_and_pack 2) && P3=$(commit_and_pack 3) && @@ -534,6 +536,7 @@ test_expect_success 'setup for --write-midx tests' ' ( cd midx && git config core.multiPackIndex true && + git config maintenance.auto false && test_commit base ) From ea7d894f449d7f212ddf8a12a67f78467581b23f Mon Sep 17 00:00:00 2001 From: Patrick Steinhardt Date: Tue, 24 Feb 2026 09:45:47 +0100 Subject: [PATCH 3/8] t34xx: don't expire reflogs where it matters We have a couple of tests in the t34xx range that rely on reflogs. This never really used to be a problem, but in a subsequent commit we will change the default maintenance strategy from "gc" to "geometric", and this will cause us to drop all reflogs in these tests. This may seem surprising and like a bug at first, but it's actually not. The main difference between these two strategies is that the "gc" strategy will skip all maintenance in case the object database is in a well-optimized state. The "geometric" strategy has separate subtasks though, and the conditions for each of these tasks is evaluated on a case by case basis. This means that even if the object database is in good shape, we may still decide to expire reflogs. So why is that a problem? The issue is that Git's test suite hardcodes the committer and author dates to a date in 2005. Interestingly though, these hardcoded dates not only impact the commits, but also the reflog entries. The consequence is that all newly written reflog entries are immediately considered stale as our reflog expiration threshold is in the range of weeks, only. It follows that executing `git reflog expire` will thus immediately purge all reflog entries. This hasn't been a problem in our test suite by pure chance, as the repository shapes simply didn't cause us to perform actual garbage collection. But with the upcoming "geometric" strategy we _will_ start to execute `git reflog expire`, thus surfacing this issue. Prepare for this by explicitly disabling reflog expiration in tests impacted by this upcoming change. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- t/t3404-rebase-interactive.sh | 6 ++++++ t/t3406-rebase-message.sh | 6 ++++++ t/t3431-rebase-fork-point.sh | 6 ++++++ t/t3432-rebase-fast-forward.sh | 6 ++++++ 4 files changed, 24 insertions(+) diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh index e778dd8ae4..3e44562afa 100755 --- a/t/t3404-rebase-interactive.sh +++ b/t/t3404-rebase-interactive.sh @@ -31,6 +31,12 @@ Initial setup: . "$TEST_DIRECTORY"/lib-rebase.sh test_expect_success 'setup' ' + # Commit dates are hardcoded to 2005, and the reflog entries will have + # a matching timestamp. Maintenance may thus immediately expire + # reflogs if it was running. + git config set gc.reflogExpire never && + git config set gc.reflogExpireUnreachable never && + git switch -C primary && test_commit A file1 && test_commit B file1 && diff --git a/t/t3406-rebase-message.sh b/t/t3406-rebase-message.sh index a1d7fa7f7c..bc51a9d3a7 100755 --- a/t/t3406-rebase-message.sh +++ b/t/t3406-rebase-message.sh @@ -8,6 +8,12 @@ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME . ./test-lib.sh test_expect_success 'setup' ' + # Commit dates are hardcoded to 2005, and the reflog entries will have + # a matching timestamp. Maintenance may thus immediately expire + # reflogs if it was running. + git config set gc.reflogExpire never && + git config set gc.reflogExpireUnreachable never && + test_commit O fileO && test_commit X fileX && git branch fast-forward && diff --git a/t/t3431-rebase-fork-point.sh b/t/t3431-rebase-fork-point.sh index be09fc78c1..4336f417c2 100755 --- a/t/t3431-rebase-fork-point.sh +++ b/t/t3431-rebase-fork-point.sh @@ -17,6 +17,12 @@ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME # C was formerly part of main but main was rewound to remove C # test_expect_success setup ' + # Commit dates are hardcoded to 2005, and the reflog entries will have + # a matching timestamp. Maintenance may thus immediately expire + # reflogs if it was running. + git config set gc.reflogExpire never && + git config set gc.reflogExpireUnreachable never && + test_commit A && test_commit B && test_commit C && diff --git a/t/t3432-rebase-fast-forward.sh b/t/t3432-rebase-fast-forward.sh index 5086e14c02..181d19dcc1 100755 --- a/t/t3432-rebase-fast-forward.sh +++ b/t/t3432-rebase-fast-forward.sh @@ -11,6 +11,12 @@ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME . ./test-lib.sh test_expect_success setup ' + # Commit dates are hardcoded to 2005, and the reflog entries will have + # a matching timestamp. Maintenance may thus immediately expire + # reflogs if it was running. + git config set gc.reflogExpire never && + git config set gc.reflogExpireUnreachable never && + test_commit A && test_commit B && test_commit C && From 0894704369579cb99bba21e88e9ec7ff3852deee Mon Sep 17 00:00:00 2001 From: Patrick Steinhardt Date: Tue, 24 Feb 2026 09:45:48 +0100 Subject: [PATCH 4/8] t5400: explicitly use "gc" strategy In t5400 we verify that git-receive-pack(1) runs automated repository maintenance in the remote repository. The check is performed indirectly by observing an effect that git-gc(1) would have, namely to prune a temporary object from the object database. In a subsequent commit we're about to switch to the "geometric" strategy by default though, and here we stop observing that effect. Adapt the test to explicitly use the "gc" strategy to prepare for that upcoming change. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- t/t5400-send-pack.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh index 83b42ff073..b32a0a6aa7 100755 --- a/t/t5400-send-pack.sh +++ b/t/t5400-send-pack.sh @@ -187,6 +187,7 @@ test_expect_success 'receive-pack runs auto-gc in remote repo' ' cd child && git config gc.autopacklimit 1 && git config gc.autodetach false && + git config maintenance.strategy gc && git branch test_auto_gc && # And create a file that follows the temporary object naming # convention for the auto-gc to remove From 94f5d9f09e3c25a2c1efafcab7697a3387c80b4b Mon Sep 17 00:00:00 2001 From: Patrick Steinhardt Date: Tue, 24 Feb 2026 09:45:49 +0100 Subject: [PATCH 5/8] t5510: explicitly use "gc" strategy One of the tests in t5510 wants to verify that auto-gc does not lock up when fetching into a repository. Adapt it to explicitly pick the "gc" strategy for auto-maintenance. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- t/t5510-fetch.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh index c69afb5a60..5dcb4b51a4 100755 --- a/t/t5510-fetch.sh +++ b/t/t5510-fetch.sh @@ -1321,6 +1321,7 @@ test_expect_success 'fetching with auto-gc does not lock up' ' git config fetch.unpackLimit 1 && git config gc.autoPackLimit 1 && git config gc.autoDetach false && + git config maintenance.strategy gc && GIT_ASK_YESNO="$TRASH_DIRECTORY/askyesno" git fetch --verbose >fetch.out 2>&1 && test_grep "Auto packing the repository" fetch.out && ! grep "Should I try again" fetch.out From 38ae87c1ba6b070a4ab69d9ae08c39bcbfcba00c Mon Sep 17 00:00:00 2001 From: Patrick Steinhardt Date: Tue, 24 Feb 2026 09:45:50 +0100 Subject: [PATCH 6/8] t6500: explicitly use "gc" strategy The test in t6500 explicitly wants to exercise git-gc(1) and is thus highly specific to the actual on-disk state of the repository and specifically of the object database. An upcoming change modifies the default maintenance strategy to be the "geometric" strategy though, which breaks a couple of assumptions. One fix would arguably be to disable auto-maintenance altogether, as we do want to explicitly verify git-gc(1) anyway. But as the whole test suite is about git-gc(1) in the first place it feels more sensible to configure the default maintenance strategy to be "gc". Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- t/t6500-gc.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/t/t6500-gc.sh b/t/t6500-gc.sh index bef472cb8d..ea9aaad470 100755 --- a/t/t6500-gc.sh +++ b/t/t6500-gc.sh @@ -11,6 +11,7 @@ test_expect_success 'setup' ' # behavior, make sure we always pack everything to one pack by # default git config gc.bigPackThreshold 2g && + git config set --global maintenance.strategy gc && test_oid_init ' From d2fbe9af79148a93bbcc2fa540e21e9fe3594b65 Mon Sep 17 00:00:00 2001 From: Patrick Steinhardt Date: Tue, 24 Feb 2026 09:45:51 +0100 Subject: [PATCH 7/8] t7900: prepare for switch of the default strategy The t7900 test suite is exercising git-maintenance(1) and is thus of course heavily reliant on the exact maintenance strategy. This reliance comes in two flavors: - One test explicitly wants to verify that git-gc(1) is run as part of `git maintenance run`. This test is adapted by explicitly picking the "gc" strategy. - The other tests assume a specific shape of the object database, which is dependent on whether or not we run auto-maintenance before we come to the actual subject under test. These tests are adapted by disabling auto-maintenance. With these changes t7900 passes with both "gc" and "geometric" default strategies. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- t/t7900-maintenance.sh | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh index fe344f47ee..4700beacc1 100755 --- a/t/t7900-maintenance.sh +++ b/t/t7900-maintenance.sh @@ -45,7 +45,8 @@ test_expect_success 'help text' ' test_grep "usage: git maintenance" err ' -test_expect_success 'run [--auto|--quiet]' ' +test_expect_success 'run [--auto|--quiet] with gc strategy' ' + test_config maintenance.strategy gc && GIT_TRACE2_EVENT="$(pwd)/run-no-auto.txt" \ git maintenance run 2>/dev/null && GIT_TRACE2_EVENT="$(pwd)/run-auto.txt" \ @@ -499,6 +500,7 @@ test_expect_success 'maintenance.incremental-repack.auto' ' ( cd incremental-repack-true && git config core.multiPackIndex true && + git config maintenance.auto false && run_incremental_repack_and_verify ) ' @@ -509,6 +511,7 @@ test_expect_success 'maintenance.incremental-repack.auto (when config is unset)' ( cd incremental-repack-unset && test_unconfig core.multiPackIndex && + git config maintenance.auto false && run_incremental_repack_and_verify ) ' @@ -619,6 +622,7 @@ test_expect_success 'geometric repacking with --auto' ' git init repo && ( cd repo && + git config set maintenance.auto false && # An empty repository does not need repacking, except when # explicitly told to do it. From 452b12c2e0fe7a18f9487f8a090ce46bef207177 Mon Sep 17 00:00:00 2001 From: Patrick Steinhardt Date: Tue, 24 Feb 2026 09:45:52 +0100 Subject: [PATCH 8/8] builtin/maintenance: use "geometric" strategy by default The git-gc(1) command has been introduced in the early days of Git in 30f610b7b0 (Create 'git gc' to perform common maintenance operations., 2006-12-27) as the main repository maintenance utility. And while the tool has of course evolved since then to cover new parts, the basic strategy it uses has never really changed much. It is safe to say that since 2006 the Git ecosystem has changed quite a bit. Repositories tend to be much larger nowadays than they have been almost 20 years ago, and large parts of the industry went crazy for monorepos (for various wildly different definitions of "monorepo"). So the maintenance strategy we used back then may not be the best fit nowadays anymore. Arguably, most of the maintenance tasks that git-gc(1) does are still perfectly fine today: repacking references, expiring various data structures and things like tend to not cause huge problems. But the big exception is the way we repack objects. git-gc(1) by default uses a split strategy: it performs incremental repacks by default, and then whenever we have too many packs we perform a large all-into-one repack. This all-into-one repack is what is causing problems nowadays, as it is an operation that is quite expensive. While it is wasteful in small- and medium-sized repositories, in large repos it may even be prohibitively expensive. We have eventually introduced git-maintenance(1) that was slated as a replacement for git-gc(1). In contrast to git-gc(1), it is much more flexible as it is structured around configurable tasks and strategies. So while its default "gc" strategy still uses git-gc(1) under the hood, it allows us to iterate. A second strategy it knows about is the "incremental" strategy, which we configure when registering a repository for scheduled maintenance. This strategy isn't really a full replacement for git-gc(1) though, as it doesn't know to expire unused data structures. In Git 2.52 we have thus introduced a new "geometric" strategy that is a proper replacement for the old git-gc(1). In contrast to the incremental/all-into-one split used by git-gc(1), the new "geometric" strategy maintains a geometric progression of packfiles, which significantly reduces the number of all-into-one repacks that we have to perform in large repositories. It is thus a much better fit for large repositories than git-gc(1). Note that the "geometric" strategy isn't perfect though: while we perform way less all-into-one repacks compared to git-gc(1), we still have to perform them eventually. But for the largest repositories out there this may not be an option either, as client machines might not be powerful enough to perform such a repack in the first place. These cases would thus still be covered by the "incremental" strategy. Switch the default strategy away from "gc" to "geometric", but retain the "incremental" strategy configured when registering background maintenance with `git maintenance register`. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano --- Documentation/config/maintenance.adoc | 6 +++--- builtin/gc.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Documentation/config/maintenance.adoc b/Documentation/config/maintenance.adoc index d0c38f03fa..b578856dde 100644 --- a/Documentation/config/maintenance.adoc +++ b/Documentation/config/maintenance.adoc @@ -30,8 +30,7 @@ The possible strategies are: + * `none`: This strategy implies no tasks are run at all. This is the default strategy for scheduled maintenance. -* `gc`: This strategy runs the `gc` task. This is the default strategy for - manual maintenance. +* `gc`: This strategy runs the `gc` task. * `geometric`: This strategy performs geometric repacking of packfiles and keeps auxiliary data structures up-to-date. The strategy expires data in the reflog and removes worktrees that cannot be located anymore. When the @@ -40,7 +39,8 @@ The possible strategies are: are already part of a cruft pack will be expired. + This repacking strategy is a full replacement for the `gc` strategy and is -recommended for large repositories. +recommended for large repositories. This is the default strategy for manual +maintenance. * `incremental`: This setting optimizes for performing small maintenance activities that do not delete any data. This does not schedule the `gc` task, but runs the `prefetch` and `commit-graph` tasks hourly, the diff --git a/builtin/gc.c b/builtin/gc.c index 4390eee6ec..fb329c2cff 100644 --- a/builtin/gc.c +++ b/builtin/gc.c @@ -1980,7 +1980,7 @@ static void initialize_task_config(struct maintenance_run_opts *opts, strategy = none_strategy; type = MAINTENANCE_TYPE_SCHEDULED; } else { - strategy = gc_strategy; + strategy = geometric_strategy; type = MAINTENANCE_TYPE_MANUAL; }