[brettheap]

Lane: openreposhape-3 (openRepoShape-3)
Claim: #215 (comment)

Based on main. #226 (issue #195) landed as aaa40eb, and this PR's base is now main. Its fix round 1 (f48c669) was merged into this branch first (a340d0a), then main d89fffa (72f2bb6), so the PR shows only this issue's work: c800efd, fix round 1 (ddb1419) and fix round 2 (5521e82, wording).

What

git's submodule reader (submodule-config.c, parse_config) types three keys of a .gitmodules, and dies on a value it refuses for one of them. git filter-repo runs git fast-export --all, which runs that reader on the clone's checked-out .gitmodules for every gitlink the exported history adds, removes or moves (#195). git config --list reads all of these values, and _registrations checked none of them. So check said plan ok, and execute died inside the extraction after both leg repositories were made.

_registrations now refuses what git refuses. It returns git's words as a string, which is #195's single gate. The tip-or-history logic and execute's refusal through #168's shared list are #226's, on main, and are unchanged here.

• update (parse_submodule_update_strategy, submodule.c) must be exactly checkout, rebase, merge or none. A !command is refused in a .gitmodules, and so is anything else, an empty value included.
• shallow (git_config_bool) must be a boolean git_parse_maybe_bool reads. That is an empty value; true, yes, on, false, no or off in any ASCII case; or an integer git_parse_int takes: hex, octal or decimal, with a k, m or g unit, within an int.
• fetchRecurseSubmodules (parse_fetch_recurse, with die_on_error for the checked-out file) must be such a boolean or exactly on-demand.
• Every occurrence is checked. git reads the checked-out file through gitmodules_cb, which sets overwrite. So update = checkout followed by update = bogus still dies. The finding names the first key in the file that git dies on, whether it is one of adopt-project.py: a .gitmodules with a key with no value passes check when the tip holds no submodule but the history does, and execute dies in git fast-export after both legs are pushed #195's keys with no value or one of these. A name git ignores (check_submodule_name) is never read.
• The finding is plan-gitmodules-unreadable; no new id. It uses git's words with the key and the value spelled by _spelled, and says which values update and fetchRecurseSubmodules take. For example: git cannot read the source's .gitmodules for its submodules (invalid value for `submodule.b.update`: `bogus`, which is not one of `checkout`, `rebase`, `merge`, `none`), and the source holds a submodule, so `git filter-repo` fails on that file when `execute` extracts a leg, wherever the plan sends the two. Where only the history holds the gitlink, it ends with adopt-project.py: a .gitmodules with a key with no value passes check when the tip holds no submodule but the history does, and execute dies in git fast-export after both legs are pushed #195's FAILS_IN_THE_HISTORY and names the commit.
• Where gits differ, check refuses what ANY of them refuses (fix round 1). A refusal at check costs an edit to an absurd value; a death at execute costs two leg repositories. I read git's source at 2.39.5 and at every minor release from 2.40.0 to 2.51.0. The three parsers are the same in each, with one exception: git 2.50 moved git_parse_signed's bound below zero by one ((-max - 1) / factor; 2.49 has -max / factor). And a 0b number is read only by a git whose C library's strtoimax reads it (glibc 2.38 or later). So:
  • -2147483648, -2097152k, -2048m and -2g, however spelled, are refused, and the finding says …, a number git 2.49 and older refuse, and 2.50 and later read.
  • A 0b number is refused, and the finding says …, a `0b` number, which a git reads only where its C library reads C23 binary numbers (glibc 2.38 or later, for one) (fix round 2 widened this from glibc alone).
  • The cost: on git 2.50 or later, or on a C library that reads C23 binary numbers (glibc 2.39 here does), check refuses those few values although the installed git reads them. The finding's parenthesis says which gits refuse each, under adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226's frame git cannot read the source's .gitmodules.
• Not refused, because git reads them:
  • ignore with a value git does not know. ignore = bogus warns and goes on.
  • Any value of path, url or branch, branch = included.
  • A refused value in a source where no commit ever held a gitlink. As in adopt-project.py: a plan that sends .gitmodules to one leg and a submodule it registers to another passes check and execute, says adoption verified, and the assembly's recursive clone then fails: plan should ask, check should find, execute should refuse #166's S3, nothing runs the reader on it, so it still registers nothing and adopts.
  • A refused value beside a gitlink that only type changes ever moved (a file or symlink becoming a gitlink, and back). git's diff asks the reader about a changed path only when both of its sides are gitlinks; adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226's fix round, on main, passes a type change by.

Why

The issue's whole table, measured on this machine with git 2.43.0 (glibc 2.39) and git filter-repo 2.47.0. The source's .gitmodules is [submodule "b"] with path = vendor/b, url = ../b and the extra line. The plan answers .gitmodules, and vendor/ where the tip has something there, as code.

• TIP: the tip holds the gitlink.
• HISTORY: only an earlier commit did. The tip removed it and kept the .gitmodules.
• NEITHER: no commit ever held one.

In the cells, "legs left" means both Northwind-spec.git and Northwind-code.git exist in --local-remote-dir after the run.

extra line	git fast-export --all in a clone (TIP and HISTORY)	position	main 4835fb4	this head 5521e82
update = bogus	rc 128 fatal: invalid value for 'submodule.b.update'	TIP	check 0 / exec 2, legs left, stderr empty	check 1 / exec 2 REFUSED plan-gitmodules-unreadable, no remotes dir
		HISTORY	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified
update =	rc 128, same	TIP	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		HISTORY	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified
update = !cmd	rc 128, same	TIP	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		HISTORY	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified
shallow = maybe	rc 128 fatal: bad boolean config value 'maybe' for 'submodule.b.shallow'	TIP	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		HISTORY	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified
fetchRecurseSubmodules = bogus	rc 128 fatal: bad submodule.b.fetchrecursesubmodules argument: bogus	TIP	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		HISTORY	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
		NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified
ignore = bogus	rc 0, only a warning	TIP / HISTORY / NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified
branch =	rc 0	TIP / HISTORY / NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified

• On main: every exec 2 printed nothing on stderr (adopt-project.py execute exits 2 with nothing on stderr when git filter-repo fails, after both leg remotes exist: _build_the_legs swallows CommandFailed on the premise that run already reported it, and run only raises #171), and its last stdout line names remotes/Northwind-code.git. check's last line was plan ok. main a5b09c3 and adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226's 0023dde measured the same in the first round, and c800efd and ddb1419 measured as this head does.
• On this head: every refusal is REFUSED plan-gitmodules-unreadable: 1 finding(s) in …, and no remotes directory is made. "verified" means adoption verified was in execute's stdout.

Fix round 1, the same driver with a fourth position, TYPE: vendor/b a file, then a gitlink, then a file again, and no commit that adds or removes a gitlink.

extra line	position	c800efd	merge a340d0a (c800efd + f48c669)	ddb1419, and this head 5521e82
shallow = -2147483648 (git 2.43 export: rc 128 bad boolean config value)	TIP / HISTORY	check 0 / exec 2, legs left	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
fetchRecurseSubmodules = -2g (rc 128 bad … argument: -2g)	TIP / HISTORY	check 0 / exec 2, legs left	check 0 / exec 2, legs left	check 1 / exec 2 refused, no remotes dir
shallow = 0b1 (rc 0 here: glibc 2.39)	TIP / HISTORY	check 0 / exec 0 verified	check 0 / exec 0 verified	check 1 / exec 2 refused, no remotes dir (the cost named above)
update = bogus (rc 0: a type change is never read)	TYPE	check 1 / exec 2 refused	check 0 / exec 0 verified	check 0 / exec 0 verified
each of the four lines	NEITHER	check 0 / exec 0 verified	check 0 / exec 0 verified	check 0 / exec 0 verified
the first three lines	TYPE	check 0 / exec 0 verified	check 0 / exec 0 verified	check 0 / exec 0 verified

Read as git reads it. 252 .gitmodules cases written into a worktree holding a gitlink commit, git fast-export --all run on each (git 2.43.0), re-run on ddb1419. The cases cover booleans, integers with units, hex, octal and binary, the bounds, quoted whitespace, non-ASCII, case, on-demand, update values, keys given twice, other and ignored names, and key order. _registrations agrees with git on 248. The 4 others are 0b1 and 0B0 for shallow and fetchRecurseSubmodules, which this glibc 2.39 git reads and check refuses on purpose. The 10 git 2.50 bound cases, which c800efd passed and git 2.43 refuses, now agree.

Byte-identical. I ran plan, and then check on the same answered plan, over 23 sources (conftest's synthetic source, one with no .gitmodules, and the seven rows in three positions), and diffed the bytes with the plan path normalised. First round, main a5b09c3, #226's 0023dde and c800efd: plan's exit code, stdout, stderr and plan file are identical in all 23; check's are identical in the 13 whose verdict does not change, and the other 10 go from plan ok to the one finding. Fix round 1, c800efd against ddb1419: plan and check identical in all 23.

Tests

tests/test_adopt_gitmodules_values.py, 187 cases:

• Each refused row of the table, and the three numbers only some gits read, at the tip and in the history: check's exact finding, and execute's refusal in process with no remotes directory made.
• The two accepted rows, and three more values git takes, in all three positions.
• Every refused line beside no gitlink anywhere, and beside a gitlink only type changes move: check passes, and there the clone's git fast-export --all exits 0.
• The finding names the key git dies on first. This covers a key given twice, another name, an upper-case key, and two names git ignores.
• The key and the value are spelled on one line: a newline, a byte that is not UTF-8, an escape in the name, and backticks.
• A differential test that, on whatever git runs it, compares _registrations with that git's own reader in git fast-export for 85 lines. It leaves out the values on which versions or C libraries differ, so it holds on each runner's git.
• test_who_refuses_a_number_as_a_boolean: each bound for each unit, the value one past it, and the 0b cases.
• End to end: the issue's step-by-step case refused, then adopted once the source is repaired; ignore = bogus and branch = adopting at the tip and in the history; update = bogus with no gitlink anywhere, and beside a gitlink only type changes move, adopting, with the assembly's git clone --recurse-submodules exiting 0.

The shared helpers (as_human, put_gitmodules, link, named, exported_in_a_clone, planned, findings, in_the_history, and the in-process execute refusal, refused_before_any_leg) now live in tests/conftest.py, and both test_adopt_gitmodules_values.py and #226's test_adopt_history_gitlinks.py import them. No assertion in either file changed in that move. refused_before_any_leg builds its Namespace before pytest.raises (python:S5778).

Mutations, each run against the new file: restoring the wider bound and the 0b reading fails 20 of its cases; dropping #226's type-change skip in _first_gitlink fails 9 (every type-change case).

Targeted set on 5521e8281eded4f008f80a3bb89b978ca8dcb18c (main d89fffa merged, so main's new test_adopt_* files are in it), run with git-filter-repo 2.47.0 first on PATH as /usr/bin/python3 -m pytest tests/test_adopt_*.py tests/test_shape_doctor.py tests/test_repo_hygiene.py tests/test_cli_reference.py -q:

1309 passed, 1 skipped in 587.98s (0:09:47) (on ddb1419, before the main merge: 1233 passed, 1 skipped). The skip is tests/test_adopt_plan.py:393, the MedxEHR-backed plan test, which is skipped unless SHAPE_MEDXEHR_CLONE names a clone of MedxSoft/MedxEHR.

The Windows job installs no git-filter-repo, so it skips the end-to-end tests in the new file (7 cases, needs_filter_repo). The differential test needs no git-filter-repo and runs on all three operating systems.

No --help text changes, so docs/cli.md is untouched. README.md and AGENTS.md are not edited.

Composes with

main d89fffa is merged in (72f2bb6). Its merge base with this branch was a5b09c3, so git saw #226's change on both sides: four conflicting hunks in adopt-project.py, each a #215 sentence or the _refused_value call against #226's text, and an add/add in tests/test_adopt_history_gitlinks.py (the helpers moved to conftest). Each conflicting hunk took this branch's side, and every hunk that merged cleanly kept main's changes (#230's, #234's and #246's among them). The resulting tree is exactly the tree of a merge computed with f48c669 as its base (757f81f), and main's aaa40eb carries f48c669's adopt-project.py change line for line and its test_adopt_history_gitlinks.py unchanged. The PR's diff against main is the same four files as before.

Trial merges (git merge-tree --write-tree <sibling> 5521e82) against every pushed branch that touches adopt-project.py, tests/conftest.py or either test file, at 2026-10-11 ~23:10Z:

sibling	sha	result
fix/adopt-check-unsafe-path (#231, issue #196)	355ab2d	CLEAN
fix/adopt-clone-without-template (#268, issue #243)	65073c1	CLEAN
fix/adopt-late-failure-notice (also edits tests/conftest.py)	cdfb308 (local 5a8b649)	CLEAN, both
fix/adopt-plan-quote-yaml-keywords	a0ff15b (local 44c8c17)	CLEAN; the local head conflicts in one adopt-project.py hunk, the same block it conflicts in against main, so this branch adds none
fix/adopt-record-submodule-placement	2f5cda9	CLEAN
fix/adopt-relative-submodule-url (#245, issue #190)	0b996fd	CLEAN
fix/adopt-report-filter-repo-failure (#184, issue #171)	f416e13	CLEAN
fix/adopt-root-kept-symlinks	04792d2 (local b37159a)	CONFLICT in adopt-project.py and scripts/shape_materialize.py (one hunk each; local: one adopt-project.py hunk), byte-identical to its conflict against main, so this branch adds none
fix/adopt-spell-finding-paths (#223, issue #212)	508befa	CLEAN
fix/adopt-template-values-utf8 (#270, issue #255)	aed9190	CLEAN
fix/plan-literal-follow-up-grep (#228, issue #216)	f0d4334	CLEAN

#226's branch, #230, #234 and #246 have landed on main and come with the merge. main has since moved to eb6df75 (#220, shape-doctor.py and its test); it trial-merges CLEAN and is not merged here. A sibling that edits test_adopt_history_gitlinks.py's helper block would conflict with their removal here; none of the branches above does.

Left out

• adopt-project.py: a .gitmodules with a key with no value passes check when the tip holds no submodule but the history does, and execute dies in git fast-export after both legs are pushed #195's missing value for '<key>' still prints the key in git's single quotes, not through _spelled, so a submodule name holding a control character reaches that finding raw. That is adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226's text, or adopt-project.py check and execute print a source path raw in a FINDING, so a \r, \n, \x85, U+2028 or ESC in a name overwrites, splits or escapes the line on a terminal, where plan's questions spell the same path with _spelled #212's scope.
• Lane openRepoShape-2's note for adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226: the history scan reads --branches, which includes a prior adoption's adopt/three-repo-shape, a branch _extract_leg's checkout -B shadows in the clone; on a re-run over a once-adopted source check names a gitlink the extraction never exports. That is adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226's scan, and this finding inherits it.

Closes #215

🤖 Generated with Claude Code

Summary by Sourcery

Reject .gitmodules values that Git's submodule reader cannot process before adoption begins, while preserving valid and contextually unread values.

New Features:

• Detect git-submodule configuration values that Git refuses and report them as plan-gitmodules-unreadable findings during checks.
• Prevent execution from creating leg repositories when unreadable .gitmodules values are detected.

Bug Fixes:

• Prevent adoption from reaching git fast-export failures caused by invalid update, shallow, or fetchRecurseSubmodules values.
• Handle Git-version and C-library differences when validating boolean numeric values.

Enhancements:

• Centralize .gitmodules test helpers and add comprehensive coverage for accepted, rejected, repeated, ignored, malformed, and history-only values.

Tests:

• Add end-to-end, differential, and compatibility tests confirming check and execute behavior matches Git's submodule reader.

[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 1 day and 4 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[brettheap]

(lane openRepoShape-3, 2026-10-11T19:40Z) @codex review

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[sourcery-ai]

Reviewer's Guide

The PR makes check emulate the Git submodule reader for the typed .gitmodules values that can abort git fast-export, reports a precise plan-gitmodules-unreadable finding, and causes execute to refuse before creating leg repositories; extensive tests verify Git-version-aware parsing, edge cases, history/tip behavior, and successful adoption of unaffected inputs.

Sequence diagram for .gitmodules validation before adoption

sequenceDiagram
    participant User
    participant Check as check
    participant Registrations as _registrations
    participant Gitmodules as .gitmodules
    participant Execute as execute
    participant FastExport as git fast-export

    User->>Check: check plan
    Check->>Registrations: _registrations(git config --list)
    Registrations->>Gitmodules: inspect typed values
    alt Git-refused value on a relevant gitlink
        Registrations-->>Check: plan-gitmodules-unreadable
        Check-->>User: finding
        User->>Execute: execute plan
        Execute-->>User: refuse before leg repositories
    else Accepted value or no gitlink
        Registrations-->>Check: registrations
        Check-->>User: plan ok
        User->>Execute: execute plan
        Execute->>FastExport: export source history
        FastExport-->>Execute: extraction succeeds
        Execute-->>User: adoption verified
    end

Loading

State diagram for adoption with unreadable .gitmodules

stateDiagram-v2
    [*] --> Plan
    Plan --> Check
    Check --> Refused: typed value Git rejects and a gitlink exists
    Check --> Ready: value accepted or no gitlink in tip/history
    Refused --> [*]: plan-gitmodules-unreadable
    Ready --> Execute
    Execute --> Verified: fast-export succeeds
    Execute --> ExtractionFailure: Git rejects during fast-export
    Verified --> [*]
    ExtractionFailure --> [*]

Loading

Flow diagram for Git-compatible .gitmodules value checks

flowchart TD
    A[Read each .gitmodules entry] --> B{Relevant submodule name?}
    B -- No --> C[Ignore entry]
    B -- Yes --> D{Typed key?}
    D -- No --> E[Apply existing registration handling]
    D -- Yes --> F{Key and value accepted by Git?}
    F -- Yes --> E
    F -- No --> G[Return Git-style refusal text]
    G --> H[Record plan-gitmodules-unreadable]
    H --> I[check reports finding]
    I --> J[execute refuses before leg repositories]

Loading

File-Level Changes

Change	Details	Files
Detect .gitmodules values that Git’s submodule reader rejects and surface them during planning/checking.	Added typed-key recognition for update, shallow, and fetchRecurseSubmodules. Implemented Git-compatible validation for update strategies, booleans, integer units/bounds, and on-demand. Preserved Git’s first-failure ordering, duplicate-key handling, ignored-name behavior, and escaped/spelled diagnostic values. Integrated value refusals with the existing registration scan and plan-gitmodules-unreadable finding path.	adopt-project.py
Prevent execution from creating leg repositories before a known Git submodule-reader failure.	Ensure refused typed values are reported through the shared check/execute refusal flow. Keep accepted-but-warning values and sources with no historical gitlink adoptable.	adopt-project.py
Add comprehensive regression and differential coverage for Git-compatible .gitmodules parsing.	Test refused values at the tip and only in history, including exact findings and no-created-remotes execution behavior. Test accepted values, ignored names, duplicate and ordering cases, spelling/encoding edge cases, and no-gitlink sources. Compare registration validation with the installed Git reader and cover version/library-dependent numeric boundaries. Add end-to-end adoption, repair, and recursive-clone scenarios.	tests/test_adopt_gitmodules_values.py

Possibly linked issues

• adopt-project.py check accepts a .gitmodules value git's submodule reader rejects (update = bogus, update =, update = !cmd, shallow = maybe, fetchRecurseSubmodules = bogus), so plan ok is followed by execute dying in git filter-repo after both leg remotes exist, whether the tip or only the history holds the gitlink #215: The PR directly implements the issue by validating update, shallow, and fetchRecurseSubmodules values before extraction.

---

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.

[brettheap]

(lane openRepoShape-2, 2026-10-11T20:13:53Z)

Lane openRepoShape-2 reviewed PR #240 at c800efd read-only, in its own detached worktrees. Nothing was authored, and this lane holds no claim.

MERGEABLE WITH NITS. Sequencing: merge after #226, and only once this branch has taken #226's current head f48c669. It need not take main 54aa69a first.

Findings:

• Take f48c669 first. c800efd inherits 0023dde's scan, which counts a type change. A gitlink that only type changes move, beside update = bogus, is refused (check 1), though git fast-export --all in a clone exits 0. With f48c669 merged in, the same source checks 0 and adopts.
• Nit, adopt-project.py:404 and :370. check takes git 2.50's bound and 0b numbers. So on git 2.49 and older, shallow = -2147483648 (or -2097152k, -2048m, -2g) passes check, and execute dies with both legs left. Measured on git 2.43 at the tip. It is documented and implausible, but it errs in the costly direction.
• Nit. SonarCloud's gate is red: new duplicated lines 6.3% against a 3% threshold. The duplicates are helpers copied from tests/test_adopt_history_gitlinks.py, at tests/test_adopt_gitmodules_values.py:141-168, :287-306 and :410. There is also python:S5778 at :297. tests, tests-macos and tests-windows pass.
• Nit. The body's "Composes with" table is stale: six sibling SHAs have moved, and adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226 is now f48c669.
• Note for adopt-project.py: a .gitmodules git's submodule reader cannot read is a check finding and an execute refusal when the tip holds no submodule but the history of the source's branches and tags does, and so is ignore, update or branch with no value beside any submodule, so execute no longer dies in git fast-export after both leg repositories exist (#195) #226. _exported_gitlink scans --branches --tags (:543), including a prior adopt/three-repo-shape. _extract_leg's checkout -B (:2425) shadows that branch, so on a re-run the finding names a mount commit the extraction never exports.

The body links #215 with Closes #215. GitHub records no closing reference while the base is fix/adopt-history-gitlinks.

Reproduction: on a5b09c3 the issue's table shows check 0, exec 2, empty stderr, both legs left. On head the five rows give check 1, then REFUSED plan-gitmodules-unreadable, no remotes directory. The rows git reads adopt on both. An independent differential of 173 values agrees with git 2.43 except the 2 documented bound values.

Tests:

• Head: the new file 158 passed; tests/test_adopt_*.py plus doctor, hygiene and cli-reference 1199 passed, 1 skipped.
• 0023dde with the new file: 86 failed, 72 passed, all for the right reason.
• a5b09c3 with the new file: 87 failed, 71 passed.
• Six mutants of the decisive lines: all killed.
• Merge with 54aa69a: 346 passed.
• Merge with f48c669: 334 passed.

Merges:

• With 54aa69a: rc 0.
• With f48c669: rc 1, one hunk in the Source.registered_submodules docstring. Resolve it by keeping f48c669's wording and inserting adopt-project.py: a .gitmodules value git's submodule reader refuses (update = bogus, update =, update = !cmd, shallow = maybe, fetchRecurseSubmodules = bogus) is a check finding and an execute refusal, so execute no longer dies in git fast-export after both leg repositories exist, whether the tip or only the history holds the gitlink (#215) #240's "A VALUE ..." sentences. The code composes, and both PRs share plan-gitmodules-unreadable with no new ids.
• Of 13 open heads touching adopt-project.py, 11 merge clean. d5fdc22 and b0c959e conflict with main already, and c800efd adds no conflict.

Report: opensoft/brett-wip handoffs/xFactory/attachments/lane-openRepoShape-2/review240-c800efd/final-report.md

[brettheap]

(lane openRepoShape-3, 2026-10-11T21:37Z) fix round 1 (independent review, codex is out of quota): merged #226's fix round 1 (f48c669) into this branch (a340d0a), resolving the one docstring conflict in Source.registered_submodules as f48c669's paragraph plus this branch's "A VALUE ..." sentences, with no new finding id; then ddb1419. Lane openRepoShape-2's sequencing item: a gitlink only type changes move, beside a refused value, was refused on c800efd although git fast-export in a clone exits 0; with f48c669 merged it passes and adopts, and a new type-changes position covers it (check passes every refused line there, the clone's export exits 0, and update = bogus adopts and clones end to end). Lane 2's nit at adopt-project.py:370 and :404: check now refuses what ANY git refuses. _who_refuses_a_boolean replaces _git_reads_as_a_boolean, so -2147483648, -2097152k, -2048m and -2g (git 2.49 and older refuse them) and 0b numbers (only glibc 2.38+ builds read them) are plan-gitmodules-unreadable, and the finding says which gits refuse each; measured with git 2.43, shallow = -2147483648 and fetchRecurseSubmodules = -2g went from check 0 / exec 2 with both legs left (c800efd, a340d0a) to check 1 / exec 2 with no remotes dir. The cost, named in the body: on a git that reads those few values, check refuses them anyway. SonarCloud: the helpers both test files repeated (as_human, put_gitmodules, link, named, exported_in_a_clone, planned, findings, in_the_history, and the in-process execute refusal, now refused_before_any_leg) live in tests/conftest.py, with no assertion changed; python:S5778 is fixed there by building the Namespace before pytest.raises. Review finding 3 (the 252-case sweep predating the wording) is re-run on ddb1419: 248 agree with git 2.43, and the 4 others are the deliberate 0b refusals. Mutations: restoring the wide bound fails 20 cases, dropping the type-change skip fails 9. Body refreshed (tables, Composes with at current shas: main 4835fb4 and every sibling CLEAN). Targeted set (tests/test_adopt_*.py + doctor, hygiene, cli-reference) on ddb141916a1a10cbb598b532401f0b677c8770cc: 1233 passed, 1 skipped in 589.91s (the MedxEHR skip). main is not merged here; that waits for #226 to land.

[brettheap]

(lane openRepoShape-3, 2026-10-11T23:19Z) fix round 2 (independent review, codex is out of quota): #226 landed as aaa40eb, so this PR's base is now main and closingIssuesReferences holds #215. Merged main d89fffa into the branch (72f2bb6): four conflicting hunks in adopt-project.py (each a #215 sentence or the _refused_value call against #226's text) and an add/add in tests/test_adopt_history_gitlinks.py (the helper move), each conflicting hunk resolved to this branch's side, every clean hunk keeping main's changes (#230, #234, #246 among them); the resulting tree is exactly the tree of a merge computed with f48c669 as its base (757f81f), and main's aaa40eb carries f48c669's adopt-project.py change line for line and its history test file unchanged, so conftest's helpers serve it as they served f48c669's. Then 5521e82: the verifier's optional nit 1 taken, so the 0b refusal says "a git reads only where its C library reads C23 binary numbers (glibc 2.38 or later, for one)" instead of naming glibc alone; nit 2 (the frame "git cannot read the source's .gitmodules" over a value the installed git reads) left, as that frame is #226's shared builder on main and the parenthesis says which gits refuse it. Re-measured on 5521e82: the issue table and the fix-round-1 table give the same exit codes and remotes as on ddb1419. Trial merges at 23:10Z are CLEAN but fix/adopt-root-kept-symlinks (and lane 3's local heads of it and of fix/adopt-plan-quote-yaml-keywords), whose conflicts are byte-identical to their conflicts against main; main has since moved to eb6df75 (#220), which merges clean and is not merged here. Body updated (base, tables, composition, tests). Targeted set (tests/test_adopt_*.py + doctor, hygiene, cli-reference) on 5521e8281eded4f008f80a3bb89b978ca8dcb18c: 1309 passed, 1 skipped in 587.98s (the MedxEHR skip).

[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