Re: [PATCH 1/8] t: fix races caused by background maintenance

From: Patrick Steinhardt <ps@pks.im>
Date: Aug 10, 2026, 05:20 UTC
Message-ID: <anlfk0P7UillhlUd@pks.im>
In-Reply-To: <17d460c0-564e-45fd-830e-548f60e01e01@haller-berlin.de>

On Mon, Aug 10, 2026 at 06:43:45AM +0200, Stefan Haller wrote:

Show 15 quoted lines

> On 20.02.26 11:15, Patrick Steinhardt wrote:
> > Introduce a new `GIT_TEST_MAINT_AUTO_DETACH` environment variable that
> > allows us to override the auto-detach behaviour and set that varibale in
> > our tests.
> I have just run into this problem with the lazygit test suite, and I
> worked around it there by turning off auto maintenance altogether. Some
> more details of how this affected us and why can be found in [1].
> 
> I'm fine with that solution, but I do wonder why we think this doesn't
> also affect ordinary usage. Lazygit's integration test suite doesn't do
> anything special, it simply executes git commands like a normal user
> would. Maybe a bit faster than a normal user would type them, but for
> scripts that create a bunch of files, stage them, and commit them, I see
> no reason why they shouldn't run into the same problem. Or am I missing
> something?

It does affect ordinary usage, but the expectation is that a "normal" user should not care about repository maintenance running in parallel to us. It should be completely transparent to them in the best case. Git commands should just work with concurrent maintenance, and if they don't then it's worth to have a deeper look at why it doesn't.

The reason why it's not fine for the Git test suite is that in lots of cases we assume a lot about the on-disk state of the repository. We are often reaching into internals to verify that it looks as expected, and that is of course racing with concurrent maintenance. And hence we have to be more careful than users, as they are not supposed to reach into repository internals without Git or an implementation thereof.

Patrick