From: Justin Tobler <jltobler@gmail.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>,
Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH 1/8] t: fix races caused by background maintenance
Date: Mon, 23 Feb 2026 10:01:48 -0600 [thread overview]
Message-ID: <aZx3NCv9hjap_yoP@denethor> (raw)
In-Reply-To: <20260220-b4-pks-maintenance-default-geometric-strategy-v1-1-faeb321ad13b@pks.im>
On 26/02/20 11:15AM, Patrick Steinhardt wrote:
> 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 significantly divergence from the "real
s/significantly/significant/
> 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 varibale in
s/varibale/variable/
> our tests.
>
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> run-command.c | 2 +-
> t/t5616-partial-clone.sh | 6 +++---
> t/t7900-maintenance.sh | 1 +
> t/test-lib.sh | 4 ++++
> 4 files changed, 9 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);
So now if "maintenance.autodetach" and "gc.autodetach" are both not set,
we then check for the "GIT_TEST_MAINT_AUTO_DETACH" env before defaulting
to true. Looks good.
>
> maint->git_cmd = 1;
> maint->close_object_store = 1;
[snip]
> diff --git a/t/t7900-maintenance.sh b/t/t7900-maintenance.sh
> index 7cc0ce57f8..d11d6f8f15 100755
> --- a/t/t7900-maintenance.sh
> +++ b/t/t7900-maintenance.sh
> @@ -6,6 +6,7 @@ test_description='git maintenance builtin'
>
> GIT_TEST_COMMIT_GRAPH=0
> GIT_TEST_MULTI_PACK_INDEX=0
> +sane_unset GIT_TEST_MAINT_AUTO_DETACH
I assume here we are unsetting the env for testing purposes. It might be
nice to leave some sort of breadcrumb comment here to explain to future
readers.
> test_lazy_prereq XMLLINT '
> xmllint --version
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 0fb76f7d11..aa805a01ce 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1947,6 +1947,10 @@ test_lazy_prereq COMPAT_HASH '
> GIT_TEST_MAINT_SCHEDULER="none:exit 1"
> export GIT_TEST_MAINT_SCHEDULER
>
> +# Ensure that tests cannot race with background maintenance by default.
> +GIT_TEST_MAINT_AUTO_DETACH="false"
> +export GIT_TEST_MAINT_AUTO_DETACH
Looks good.
-Justin
next prev parent reply other threads:[~2026-02-23 16:01 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 10:15 [PATCH 0/8] builtin/maintenance: use "geometric" strategy by default Patrick Steinhardt
2026-02-20 10:15 ` [PATCH 1/8] t: fix races caused by background maintenance Patrick Steinhardt
2026-02-23 16:01 ` Justin Tobler [this message]
2026-02-20 10:15 ` [PATCH 2/8] t: disable maintenance where we verify object database structure Patrick Steinhardt
2026-02-23 16:07 ` Justin Tobler
2026-02-20 10:15 ` [PATCH 3/8] t34xx: don't expire reflogs where it matters Patrick Steinhardt
2026-02-23 0:48 ` Derrick Stolee
2026-02-23 16:15 ` Justin Tobler
2026-02-20 10:15 ` [PATCH 4/8] t5400: explicitly use "gc" strategy Patrick Steinhardt
2026-02-20 10:15 ` [PATCH 5/8] t5510: " Patrick Steinhardt
2026-02-20 10:15 ` [PATCH 6/8] t6500: " Patrick Steinhardt
2026-02-20 10:15 ` [PATCH 7/8] t7900: prepare for switch of the default strategy Patrick Steinhardt
2026-02-20 10:15 ` [PATCH 8/8] builtin/maintenance: use "geometric" strategy by default Patrick Steinhardt
2026-02-23 0:52 ` Derrick Stolee
2026-02-23 9:49 ` Patrick Steinhardt
2026-02-23 16:48 ` Justin Tobler
2026-02-24 8:15 ` Patrick Steinhardt
2026-02-23 0:53 ` [PATCH 0/8] " Derrick Stolee
2026-02-24 8:45 ` [PATCH v2 " Patrick Steinhardt
2026-02-24 8:45 ` [PATCH v2 1/8] t: fix races caused by background maintenance Patrick Steinhardt
2026-02-24 8:45 ` [PATCH v2 2/8] t: disable maintenance where we verify object database structure Patrick Steinhardt
2026-02-24 8:45 ` [PATCH v2 3/8] t34xx: don't expire reflogs where it matters Patrick Steinhardt
2026-02-24 8:45 ` [PATCH v2 4/8] t5400: explicitly use "gc" strategy Patrick Steinhardt
2026-02-24 8:45 ` [PATCH v2 5/8] t5510: " Patrick Steinhardt
2026-02-24 8:45 ` [PATCH v2 6/8] t6500: " Patrick Steinhardt
2026-02-25 10:13 ` Toon Claes
2026-02-24 8:45 ` [PATCH v2 7/8] t7900: prepare for switch of the default strategy Patrick Steinhardt
2026-02-24 8:45 ` [PATCH v2 8/8] builtin/maintenance: use "geometric" strategy by default Patrick Steinhardt
2026-02-24 12:12 ` Derrick Stolee
2026-02-25 10:33 ` Toon Claes
2026-02-24 18:54 ` [PATCH v2 0/8] " Justin Tobler
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=aZx3NCv9hjap_yoP@denethor \
--to=jltobler@gmail.com \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.com \
--cc=ps@pks.im \
--cc=stolee@gmail.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