public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
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

  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