[brettheap]

Lane: openreposhape-5 (openRepoShape-5)
Claim: #645 (comment)

What changed. One session fixture in tests/conftest.py, no_auto_maintenance (autouse), and one new test file, tests/test_no_auto_maintenance.py. No shipped file and no other test file changes. Four commits: the fix and its tests (e2110f8), a comment (accc7d2), and the fix round below (8cfc8eb, and 979bb39, which only shares a test helper).

The fixture sets gc.auto=0 and maintenance.auto=false for every git the session starts, in two scopes:

• Command scope (GIT_CONFIG_COUNT), appended after the entries the environment already holds (the Windows job holds two). Every git the suite starts, every git a tool under test starts, and every git a git submodule starts inherits it. It outranks every config file.
• A global config file (GIT_CONFIG_GLOBAL, in the basetemp). It includes the global config git would read without it (the file GIT_CONFIG_GLOBAL already named, or $XDG_CONFIG_HOME/git/config and then ~/.gitconfig) and sets the two keys after it. This one is for the receive-pack a push starts in a local remote: git starts it with GIT_CONFIG_COUNT and GIT_CONFIG_PARAMETERS removed, so command scope never reaches it. Where HOME is unset the ~/ paths are left out, and an empty GIT_CONFIG_GLOBAL includes nothing (fix round, below).

A comment beside #440's note in clone_just_pushed says why, names both sites, and says what is left.

Why. shutil.copytree reads a repository's objects/ one file at a time. The suite copies a repository a fixture has just committed in, fetched into or pushed to in 139 places. Each git commit, merge and fetch, and the receive-pack in a remote after a push, runs git maintenance run --auto as it finishes. From git's source:

• git 2.46: the auto run stays in the foreground.
• git 2.47: it is started with --detach, takes objects/maintenance.lock and then detaches, so the command returns while it runs.
• git 2.52 and 2.53: the default strategy is still gc, which does nothing below 6700 loose objects.
• git 2.54: the default strategy is geometric. Its repack runs when packs are out of geometric order, or once its estimate, taken from objects/17 alone, is above 256 loose objects, so two loose objects there are enough (maintenance.geometric-repack.auto, 100, rounded up). It deletes the loose objects it packed.

So on a current git, a copy taken just after a commit can find a loose object gone. It happened twice on the Linux runner:

• holder (tests/test_family.py:129), in test_family_member_name.py (lane 1's report on docs/release-notes/v1.0.0.md: the v1.0.0 release notes, a draft for Brett to amend before he tags, saying what 1.0 contains and promises, how to pin it by commit, what changed on the way grouped by the five tracking areas, and every known limit as the input that triggers it and what the person sees (#472) #473);
• the_standard_moved (tests/test_doctor_pin_restore_merges.py:99), a copy of the session's standard with its .git, in test_copies_neither_side_edited_are_taken_whole_with_the_pin on setup-project.py: step (3) refuses a parent nobody can write in and a drive that is not there, step (4) verifies a chain from --pin-source, --pin no longer takes a flag as its value, and step (5) says a printed plan was refused (#608) #623's run 38895011713: shutil.Error ... standard5/openRepoShape/.git/objects/1e ... [Errno 2] (lane 2's docs/release-notes/v1.0.0.md: the v1.0.0 release notes, a draft for Brett to amend before he tags, saying what 1.0 contains and promises, how to pin it by commit, what changed on the way grouped by the five tracking areas, and every known limit as the input that triggers it and what the person sees (#472) #473 comment 6215422231). The same function copies moved at :102 just after a commit in it.

Both are covered by the same session setting: the commits before each copy run under os.environ (commit_all passes {**os.environ, ...}).

A listing of .git/objects taken before and after such a repack also differs: lane 3's objects changed in tests/test_family_bump_remove_rollback.py (#736's Linux run 38981191418), 37 loose objects packed into two. The same setting covers it (i645 on #645).

Decisions and evidence.

• Option A (the suite's environment), not B or C.

  • B (config in each copied repository) would have to reach repositories the tools under test create themselves, such as the bare remotes scaffold-project.py --local-remote-dir makes and pushes into before a test sees them. A config written after that first push is too late.
  • C (a copy that survives a repack) cannot be made safe. A copy can list objects/pack/ before the new pack lands, and then a loose-object directory after it was emptied. That copy succeeds and is missing objects.
  • A covers all 139 places from one place.

• Two scopes, not one. Probe on git 2.43, pushing into a local bare remote with receive.denyDeletes=true given each way:

  • with GIT_CONFIG_COUNT, the branch was deleted;
  • with -c, deleted;
  • through a file:// URL with GIT_CONFIG_COUNT, deleted;
  • with GIT_CONFIG_GLOBAL, remote: error: denying ref deletion (refused).

  So command scope alone misses the remotes, and ten copies are of bare remotes. A global file alone would be dropped wherever a test gives git a global file of its own (14 test files set GIT_CONFIG_GLOBAL, five more through excluding()). No test file replaces both scopes and also copies a repository. rv645, the reviewer, repeated the receive.denyDeletes probe and got the same answers, and instrumented the git calls of the batches it finished before the checkpoint: the only receive-packs that ran without both settings were in test_family_add_excludes.py and test_adopt_clone_template.py, neither of which copies a remote.

• Which verbs start auto maintenance (git 2.43 trace2): commit, fetch, pull and submodule update --remote (its fetch in the submodule) start git maintenance run --auto. A push's receive-pack starts git gc --auto --quiet. clone, submodule add and submodule update --init start none.

• Behaviour no test checks is unchanged. The person's own global config is still read: it is included, and it comes first. A test of that is part of the new file. The tests that read or set a global config (test_git_helper_identity.py, test_adopt_git_reads.py, test_tracking_branch_ref.py and others) set their own, which replaces the session's.

Fix round (8cfc8eb), on rv645's review (no MUST; two SHOULD, five NIT).

• SHOULD 1: with HOME unset every git was fatal. The file's include of ~/.config/git/config and ~/.gitconfig made git exit 128, error: could not expand include path '~/.config/git/config', in every command the session started. The estate runs with HOME set, so nothing failed here; an env -i or hermetic runner would have lost the whole suite.

  • session_global_config now writes a ~/ path only where home_is_known() (HOME is set, or os.name == "nt", where Git for Windows finds a home itself), and writes no [include] header when nothing is included. An XDG_CONFIG_HOME that is set is still included, because it needs no HOME.

  • The two test_a_persons_own_global_config... cases skip where HOME was unset. They skip on the environment and not on the file's bytes, so a fixture that dropped its includes still fails them (probe M5 below).

  • A new test, test_where_home_is_unset_the_file_is_one_git_can_read (with and without XDG_CONFIG_HOME), reads the file back through git config --global --includes. It is skipped on Windows. It and the empty-value test share one helper, probe_read_from_the_session_file, so the new tests do not repeat a body for SonarCloud's duplication gate.

  • Measured under env -u HOME -u XDG_CONFIG_HOME, run9.sh, git 2.43.0:

    file	before (accc7d2)	after (8cfc8eb)
    tests/test_clone_just_pushed.py	1 passed, 6 errors	7 passed
    tests/test_no_auto_maintenance.py	3 failed, 2 passed, 2 errors (7 tests)	9 passed, 2 skipped (11 tests)
    tests/test_family_member_name.py	not run	13 passed

    The 2 skips are the two test_a_persons_own_global_config... cases.

  • Where HOME is set and the file is written as before, nothing changes: across 27 combinations of HOME (set, unset, empty), XDG_CONFIG_HOME (set, unset, empty) and GIT_CONFIG_GLOBAL (unset, a file, empty), the file's bytes are the same as accc7d2's in the 12 where GIT_CONFIG_GLOBAL names a file or HOME is set with GIT_CONFIG_GLOBAL unset, and differ in the 15 where HOME is not set or GIT_CONFIG_GLOBAL is empty.

• SHOULD 2: nothing guarded the fixture's scope. At function scope all seven tests passed (rv645's probe), and the session fixtures scaffolded and family would have been built before the setting existed. A new test, test_the_settings_are_in_place_before_a_session_fixture_builds_a_repo, takes a session fixture as its FIRST argument, which reads GIT_CONFIG_GLOBAL and GIT_CONFIG_COUNT as that fixture sees them, and compares them with what the test sees and with the fixture's file. Pytest builds the higher scope first, and then an autouse fixture, so the fixture is only in place early enough if it is session scope and autouse.
• NIT 1: the receive-pack test failed under a person's global core.hooksPath, which hid the remote's own post-receive hook (FileNotFoundError on read-by-receive-pack). The test now sets core.hooksPath to the remote's own hooks directory in the remote's local config, which outranks a global one. Measured with GIT_CONFIG_GLOBAL naming a file that holds core.hooksPath: before, 1 failed, 4 passed, 2 skipped; after, 9 passed, 2 skipped (11 tests).
• NIT 2: an empty GIT_CONFIG_GLOBAL= was read as unset. Git 2.43 reads it as "no global config" (checked here: with HOME holding a .gitconfig probe, GIT_CONFIG_GLOBAL= does not read it). The fixture now includes nothing for an empty value: if named is not None: included = [...] if named else []. A new test, test_an_empty_GIT_CONFIG_GLOBAL_is_no_global_config_and_includes_nothing, fails on the old if named:.
• NITs 3 to 5: no code change.
  • NIT 3: test_family_dry_run.py's own NO_MAINTENANCE is redundant now. It lives in another test file that this PR leaves alone, and it is harmless.
  • NIT 4: a git config --global read without --includes sees only the session's two keys. The only reader is setup-project.py:1105, behind os.name == "nt", and no test reads it. _credential_helper_configured uses --get-all with no scope, so it still sees the person's config. The conftest comment already says so.
  • NIT 5: the version facts in the conftest comment ("2.47 detaches", "2.54 default geometric") are from git's source tags and are not run here: only git 2.43.0 is installed. The comment is unchanged.

Tests (run9.sh: gh stub first on PATH, identity blanked; git 2.43.0, Python 3.12, pytest 9.1.1).

• On the fix round (8cfc8eb; 979bb39 differs from it in the new test file alone, and the batches that read that file were run on it):
  • tests/test_no_auto_maintenance.py: 11 passed (7 from the first commit, 4 new: the HOME test twice, the empty value, the scope).
  • tests/test_no_auto_maintenance.py, tests/test_clone_just_pushed.py, tests/test_repo_hygiene.py and tests/test_git_helper_identity.py together, on 979bb39: 105 passed. With tests/test_family_dry_run.py added, on 8cfc8eb: 166 passed.
  • tests/test_adopt_git_reads.py, tests/test_tracking_branch_ref.py, tests/test_adopt_late_failure.py, tests/test_adopt_github_exits.py and tests/test_family_add_excludes.py (the tests that read or set a global config or a hooks path): 314 passed.
• On the first two commits (e2110f8 for the first four, accc7d2 for the rest; the second commit changes comment lines only). The fix round changes nothing where HOME is set and GIT_CONFIG_GLOBAL is not empty (the byte comparison above), so these were not run again:
  • Family, tests/test_family*.py (20 files): 823 passed, 19 skipped.
  • Adopt, tests/test_adopt*.py (46 files): 3463 passed, 2 skipped.
  • Doctor, tests/test_shape_doctor.py and tests/test_doctor*.py (12 files): 741 passed, 3 skipped.
  • Scaffold, tests/test_scaffold*.py: 634 passed.
  • Update-shape and bump-leg, tests/test_update_shape*.py and tests/test_bump_leg*.py (24 files): 857 passed, 4 skipped.
  • The rest of the files that copy a repository (test_bootstrap_after_bump.py, test_non_list_project_fields.py, test_pin_source_env_collisions.py, test_pin_source_unreadable.py, test_shape_pin_files_not_a_list.py, test_validator_child_encoding.py, test_siblings_family_name.py, test_bootstrap_spelling.py, test_non_utf8_git_reads.py), with test_repo_hygiene.py, test_git_helper_identity.py, test_clone_just_pushed.py and the new file: 924 passed.
  • On a merge of accc7d2 with main c6122e8: test_no_auto_maintenance.py, test_git_helper_identity.py, test_repo_hygiene.py, test_clone_just_pushed.py and test_family_member_name.py, 114 passed.

Reproductions.

• The mechanism, on git 2.43. A repository of 300 files plus two loose objects named 17…, committed under gc.auto=1, then copied at once with shutil.copytree. This is what git 2.54 does to such a repository by default. With the base's settings, 10 of 10 copies failed, then 9 of 10 ([Errno 2] on a loose object directory or file). With the fix's two entries appended after it, 0 of 10 failed.

• The emulation of the race (rv645's recipe, run on 8cfc8eb: a global gc.auto=1 that includes the person's ~/.gitconfig, plus a core.hooksPath pre-commit hook that leaves two 17… objects and drops gc.log, so git 2.43 repacks in the background after each commit; GIT_TRACE2_EVENT over the whole run). Base figures are rv645's, on a524542; head figures are the fix round's own, on 8cfc8eb:

  file	git	auto-maintenance children	repack runs	result
  test_doctor_pin_restore_merges.py	base	78 maintenance run --auto, 77 gc --auto	65	1 failed, 14 passed, 1 error
  	head	4 gc --auto (from receive-pack, inert under gc.auto=0)	0	16 passed
  test_family_member_name.py	base	19 maintenance run --auto, 29 gc --auto	15	13 passed
  	head	14 gc --auto (inert)	0	13 passed

  On the base, rv645 reproduced the symptom itself: shutil.Error ... moved/openRepoShape/.git/objects/pack/tmp_rev_..., at the_standard_moved's copy of moved (tests/test_doctor_pin_restore_merges.py:102). On head, 0 maintenance runs and 0 repacks in both files.

• The first writer's runs on the issue's file (test_family_member_name.py, base then head, 19 maintenance and 15 repacks against 0 and 0) agree.

Mutation probes. Each reverts one hunk of the fix in a throwaway clone; the new file then fails. First round (against the first seven tests):

probe	fails
fixture sets nothing	6 of 7 (all but the append test)
no command scope	test_a_commit_a_fetch_and_a_merge_start_no_maintenance[a-tests-own-global]
no global file	the receive-pack test, both person's-config cases
count overwritten, not appended	the append test
global file without the includes	both person's-config cases
the two keys before the includes	both person's-config cases
no maintenance.auto	5 tests
no gc.auto	the receive-pack test, the append test

Fix round (against the eleven tests):

probe	result	what fails
S1, no_auto_maintenance at function scope	1 failed, 10 passed	the scope test, alone (the first seven passed in rv645's run of the same mutant)
S2, not autouse	4 failed, 7 passed	the two commit/fetch/merge cases, the tool test, the receive-pack test
H1, home_is_known() always true	2 failed	test_where_home_is_unset_the_file_is_one_git_can_read, both variants
H2, the XDG include needs HOME	1 failed	the same test, the xdg variant
E1, an empty value is read as unset (if named:)	1 failed	the empty-value test
M5, the file includes nothing (the first round's probe, again)	3 failed, 8 passed	both test_a_persons_own_global_config... cases, and the xdg variant of the HOME test
K1, the receive-pack test without its own core.hooksPath, under a global core.hooksPath	1 failed, 8 passed, 2 skipped	the receive-pack test

S2 is caught by tests that ask for the setting by itself; the scope test does not catch it, because earlier tests in the file build the fixture on request. K1 only fails where a global core.hooksPath is set, as NIT 1 says.

On the base itself the new file does not import (cannot import name 'NO_AUTO_MAINTENANCE').

Merge checks (git merge-tree --write-tree on 979bb39): clean against origin/main 2fac979 and against lane 5's fix/662-insteadof-helper (4149cbb; #662 is stacked on accc7d2 and also edits tests/conftest.py: the fix round's hunks are in session_global_config, its helper home_is_known, and the comment above them). Earlier, on e2110f8 and accc7d2: clean against origin/main d4a7fab and c6122e8, #621, #622, #630, #631, #634, #635, #636, #637, #638 and #639, and the sibling branches for #646, #647, #648 and #649.

What it leaves.

• A git whose environment drops both scopes (a GIT_CONFIG_COUNT overwritten, not appended to, together with a test's own GIT_CONFIG_GLOBAL, or an environment built from nothing), and a push made under a test's own global file. No repository the suite copies is made or pushed to that way today.
• A git older than 2.32 ignores GIT_CONFIG_GLOBAL. Its receive-pack runs gc --auto, which does not detach below 6700 loose objects.
• clone_just_pushed keeps reading through git. A test with its own global file still needs it.
• test_family_dry_run.py's own NO_MAINTENANCE is now redundant, and is left alone (NIT 3).
• Not run: a real Windows job (none runs the full suite since ci: run the test suite on Linux only #597, and the HOME test is skipped on Windows), and a git newer than 2.43.

Copies found (git grep -n 'shutil.copytree(' -- tests, 152 calls):

• 127 copy a repository the suite built (non-bare, many holding .git/modules): conftest.py 1, test_family.py 18, test_shape_doctor.py 32, test_doctor_legs_members_next.py 8, the test_update_shape* files 30, and 38 more in 28 files. Four of them copy a subtree that holds no store: standard / name twice, and a member's work tree twice.
• 10 copy a bare remote, or a folder of them: test_bump_leg_paste_lines.py:95, test_doctor_unfinished_merge.py:166, test_family_add_member_id.py:239, test_family_add_refusals.py:487, :788 and :1983, test_family_dry_run.py:1446, test_family_tracking_branch.py:279, test_update_shape_landing.py:156 and test_update_shape_next_quoting.py:116.
• 2 copy a .git directory: test_adopt_clone_template.py:190 and test_scaffold_mount_ignored.py:381.
• 13 hold no repository: a template, or this checkout with .git ignored.
• test_adopt_plan.py:449 copies a clone named by SHAPE_MEDXEHR_CLONE. It is outside the suite and skipped without the variable.

No shipped script copies a repository.

Checklist candidates (rv645's; the coordinator places them):

• The import-time git probe at tests/test_family_refuse_up_front.py:75-96 runs in a throwaway directory before any session setting. It is harmless today.
• Tests that overwrite GIT_CONFIG_COUNT (14 files) lose command scope and rely on the global file alone. That holds today, and nothing guards it.

Closes #645

🤖 Generated with Claude Code

Summary by Sourcery

Prevent Git’s automatic maintenance from corrupting repository copies made during the test suite.

Bug Fixes:

• Prevent repository copies in the test suite from racing with Git’s background maintenance and losing loose objects during repacks.

Enhancements:

• Disable automatic Git maintenance for the entire test session in both command and global configuration scopes while preserving users’ existing global configuration behavior.
• Add focused coverage for maintenance suppression, remote receive-pack behavior, configuration edge cases, and fixture initialization order.

Tests:

• Add tests validating maintenance settings across Git commands, tools, local remotes, inherited configuration, unset HOME, empty global configuration, and session fixture setup.

[brettheap]

(lane openRepoShape-5, 2026-10-16T13:54Z) @codex review

[sourcery-ai]

Reviewer's Guide

The PR hardens the test suite against Git 2.47+ background maintenance races during repository copies by applying gc.auto=0 and maintenance.auto=false in both command and global configuration scopes, including remote receive-pack processes, and adds coverage for inheritance, precedence, and preservation of user Git settings.

File-Level Changes

Change	Details	Files
Disables Git’s automatic maintenance for the entire test session using both inherited command-scope configuration and a generated global configuration.	Appends gc.auto=0 and maintenance.auto=false to existing GIT_CONFIG_COUNT entries without overwriting them. Creates a basetemp global config that includes the user’s original global configuration, then applies the maintenance settings after it. Uses a session-scoped autouse fixture with MonkeyPatch so settings cover repositories, subprocesses, tools, submodules, and local push receivers while restoring the environment afterward. Adds path quoting and platform-independent global-config construction helpers.	tests/conftest.py
Adds focused tests proving maintenance is disabled across Git operations and process boundaries without suppressing unrelated user configuration.	Uses trace2 events to verify commits, fetches, merges, scaffold tooling, and remote receive-pack processes do not start maintenance. Verifies receive-pack reads both disabling settings despite command-scope variables being stripped. Checks existing command-scope entries are preserved and the new entries take precedence. Checks the original personal global configuration remains readable while the disabling settings override conflicting values.	tests/test_no_auto_maintenance.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#645	Prevent Git background auto-maintenance from rewriting or deleting objects while tests copy repository files, covering all copied repositories and Git processes that can operate on them.	✅
#645	Document why the chosen protection covers repository copies, and add deterministic tests validating the relevant command and receive-pack configuration behavior.	✅

Possibly linked issues

• tests/test_shape_doctor.py, tests/conftest.py and setup-project.py: a clone of a just-pushed --local-remote-dir bare repository is git's local clone, which links or copies each loose object file while git's background maintenance can pack and delete them, so on the macOS runner it dies failed to copy file to ... No such file or directory, every doctor test errors at setup, and setup.sh refuses after creating all three repositories #440: The PR disables gc and maintenance in command and global scopes, preventing background repacks from deleting objects during fixture copies.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-16T13:58:50.402912Z	accc7d2	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: accc7d2afe

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Preserve an explicitly empty global-config override

When the test process starts with GIT_CONFIG_GLOBAL explicitly set to an empty string, Git treats that as an override that reads no user-global configuration, but this truthiness check treats it as unset and includes ~/.config/git/config and ~/.gitconfig. This can unexpectedly reactivate settings such as commit.gpgSign=true, causing fixture commits to fail for users or CI that deliberately use GIT_CONFIG_GLOBAL= to isolate the suite; distinguish None from the empty-string override and include no original global file in the latter case.

Useful? React with 👍 / 👎.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sourcery-ai]

Sorry @brettheap, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 12 hours and 31 minutes by commenting @sourcery-ai review. Upgrade to get a review now.