tests/conftest.py:458 sets maintenance.auto=false in the template repo's local
config so git commit stops spawning the detached git maintenance run --auto --quiet --detach that was racing shutil.copytree of the template (PR #663).
Copies made by copytree inherit the key through the copied .git/config, and
git worktree add inherits it too.
A git clone does not. Measured on git 2.55.0: cloning a repo that has
maintenance.auto=false produces a clone with the key unset, and a commit in
that clone spawns the detached maintenance child again.
Live instance
tests/test_engine_worktree.py:538 clones the sandbox into tmp_path and then
commits into it via cli.main(["confirm", ...]) at :543. That commit leaves a
detached git maintenance process writing under the clone's .git/objects/.
Why this is latent, not a live flake
Nothing copytrees that clone, so there is no scandir/copy2 window for the child
to race — this is not the failure PR #663 fixed. What is off is the guard row's
headline claim in tests/test_conftest.py, "No background git process may outlive
a commit into the sandbox", which is broader than what is actually enforced.
Roughly eight other hand-rolled repos are outside the template's protection for
the same reason: tests/test_install.py:391, :4266-4267, :6068,
tests/test_verify.py:880, tests/test_resolve.py:680,
tests/test_stories_e2e.py:350, :447, :503.
Possible fix
Write the key into the shadow global config that _isolate_ambient_git_ignores
(tests/conftest.py:366) already points at, which would cover clones and the
hand-rolled repos in one place. Caveat worth checking first: making that path an
existing file changes what the git-add shield tests observe, so it is not a
free move.
Either narrow the guard's claim to what it enforces, or widen the enforcement.
tests/conftest.py:458setsmaintenance.auto=falsein the template repo's localconfig so
git commitstops spawning the detachedgit maintenance run --auto --quiet --detachthat was racingshutil.copytreeof the template (PR #663).Copies made by
copytreeinherit the key through the copied.git/config, andgit worktree addinherits it too.A
git clonedoes not. Measured on git 2.55.0: cloning a repo that hasmaintenance.auto=falseproduces a clone with the key unset, and a commit inthat clone spawns the detached maintenance child again.
Live instance
tests/test_engine_worktree.py:538clones the sandbox intotmp_pathand thencommits into it via
cli.main(["confirm", ...])at:543. That commit leaves adetached
git maintenanceprocess writing under the clone's.git/objects/.Why this is latent, not a live flake
Nothing
copytrees that clone, so there is no scandir/copy2 window for the childto race — this is not the failure PR #663 fixed. What is off is the guard row's
headline claim in
tests/test_conftest.py, "No background git process may outlivea commit into the sandbox", which is broader than what is actually enforced.
Roughly eight other hand-rolled repos are outside the template's protection for
the same reason:
tests/test_install.py:391,:4266-4267,:6068,tests/test_verify.py:880,tests/test_resolve.py:680,tests/test_stories_e2e.py:350,:447,:503.Possible fix
Write the key into the shadow global config that
_isolate_ambient_git_ignores(
tests/conftest.py:366) already points at, which would cover clones and thehand-rolled repos in one place. Caveat worth checking first: making that path an
existing file changes what the git-add shield tests observe, so it is not a
free move.
Either narrow the guard's claim to what it enforces, or widen the enforcement.