[brettheap]

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

What

git filter-repo runs git fast-export --all in a clone of the source. For every gitlink that an exported commit adds, removes or moves to another commit, git's submodule reader reads the clone's checked-out .gitmodules. #166 asked the tip tree alone. So a source whose history held a submodule, whose tip held none, and whose tip .gitmodules was one that reader cannot read went wrong in one of two ways. Either check passed it, or check said the failure would come later, in the assembly's clone. Either way, execute died in git fast-export after both leg repositories had been made, and a corrected re-run then met leg-remote-exists.

• _exported_gitlink runs one streamed git log that asks for the diffs fast-export makes, and stops at the first gitlink it sees. It reads the plan's commit plus every branch and tag of the source, which is what git clone copies.
  • Its flags are --root --diff-merges=first-parent --no-renames --ignore-submodules=none --no-replace-objects --no-show-signature, and the docstring says why each one is there.
  • It runs with GIT_GRAFT_FILE naming a file that does not exist. A clone copies no info/grafts, and --no-replace-objects leaves grafts on, so without this a graft could hide from the scan a commit that the clone exports.
  • It runs only when the tip .gitmodules cannot be read for its submodules and the tip holds no gitlink, so a readable .gitmodules (the common case) costs nothing extra.
  • A history git cannot finish reading is refused as git-failed; it is not taken to hold no gitlink.
• _first_gitlink passes a type change (T: a file or symlink becoming a gitlink, or the reverse) by. git's diff asks the submodule reader about a changed path only when both of its sides are gitlinks, so fast-export never reads .gitmodules for a type change. A gitlink that enters by a type change and leaves by a removal is still found at the removal.
• registered_submodules gives the "a key with no value registers nothing" relief (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) only when neither the tip nor that history holds a gitlink. When the history holds one, the answer is git's own words, as an InTheHistory (a str) that names the commit.
• _where_the_history_fails (new, asked first in submodule_plan_problems) handles a plan that extracts a leg. For such a plan the finding is plan-gitmodules-unreadable: … and the source's tip holds no submodule but the history `git filter-repo` rewrites does -- every branch and tag of the source, where commit bb0509690fd7 removes `vendor/b` -- so it fails on that file when `execute` extracts a leg, wherever the plan sends it. execute refuses with that finding before any leg exists. A plan that extracts no leg is still not refused.
• _registrations now also reports ignore, update and branch when they have no value. git's submodule reader dies on each of these, as it does on path and url; on branch, git 2.43 crashes (exit 139) and prints nothing. This also catches a submodule at the tip next to one of these keys, which check used to pass. fetchRecurseSubmodules and shallow with no value are read as true, and those sources still adopt.
• Printed output: SUBMODULE_REMEDIATION's sentence changed. check prints it once after its submodule findings, and execute prints it inside its refusal. It now reads "dropping it is enough in a source with no submodule at its tip or in the history of its branches and tags" (main: "in a source with no submodule, dropping it is enough"). So check's stderr changes for every source that has any submodule finding, not only for the new cases. No test or sibling quotes the old sentence.
• Docstrings corrected: the "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" paragraph, _where_git_fails and a submodule_plan_problems bullet.

Why (measured on main a5b09c3 and on this head f48c669, local remotes)

The driver builds each source with plain git, runs plan, answers every leg: null entry (.gitmodules goes to code unless the row says otherwise), then runs check and execute --yes --local-remote-dir. Measured with git 2.43.0 and git filter-repo 2.47.0, 41 cases, on main a5b09c3 and on f48c669. Unless a row says otherwise, the tip .gitmodules is [submodule "b"] followed by a bare path line (the issue's shape), and "history" means the tip holds no gitlink.

On main, execute ends every "execute 2, both legs made" row with an empty stderr. Re-running the extraction's git filter-repo --paths-from-file spec-paths.txt --force by hand in the spec clone prints git's own words, e.g. error: missing value for 'submodule.b.path' / fatal: bad config line 2 in file …/Northwind-spec/.gitmodules / Error: fast-export failed; see above.

Case	main a5b09c3	this branch
history: gitlink added then removed on the branch adopted (the issue's hist-bare-gm:code)	check 0; execute 2, both legs made (by hand: missing value for 'submodule.b.path')	check 1 plan-gitmodules-unreadable (… commit … removes vendor/b); execute 2, no leg made
same, .gitmodules dropped	check 0; execute 2, both legs made	check 1; execute 2, no leg
history, tip url with no value	check 0; execute 2, both legs made (missing value for 'submodule.b.url')	check 1; execute 2, no leg
history, tip ignore / update with no value	check 0; execute 2, both legs made (missing value for 'submodule.b.ignore' / …update')	check 1; execute 2, no leg
history, tip branch with no value	check 0; execute 2, both legs made (by hand: only Error: fast-export failed; see above.)	check 1; execute 2, no leg
history, tip line git cannot parse, kept in code	check 1, blamed on the assembly's recursive clone; execute 2, no leg	check 1, blamed on the extraction (… removes vendor/b); execute 2, no leg
history, tip line git cannot parse, dropped	check 0; execute 2, both legs made (fatal: bad config line 2)	check 1; execute 2, no leg
side branch merged / branch never merged	check 0; execute 2, both legs made	check 1 (removes / adds); execute 2, no leg
commit only a tag reaches	check 0; execute 2, both legs made	check 1 (adds); execute 2, no leg
root commit of an orphan branch	check 0; execute 2, both legs made	check 1 (adds); execute 2, no leg
branch never merged adds it, then moves it	check 0; execute 2, both legs made	check 1 (changes); execute 2, no leg
added and removed by two merges alone	check 0; execute 2, both legs made	check 1 (removes); execute 2, no leg
adding commit hidden by a refs/replace/ ref	check 0; execute 2, both legs made	check 1 (removes); execute 2, no leg
adding commit hidden by .git/info/grafts (fix round 1; 0023dde behaved as main)	check 0; execute 2, both legs made (missing value for 'submodule.b.path')	check 1 (removes); execute 2, no leg
enters by a type change (file → gitlink), leaves by a removal	check 0; execute 2, both legs made	check 1 (removes); execute 2, no leg
a clone of the source, gitlink on a tagged non-default branch	check 0; execute 2, both legs made	check 1 (adds); execute 2, no leg
tip gitlink beside ignore / update / branch with no value	check 0; execute 2, both legs made	check 1 (… and the source holds a submodule, so `git filter-repo` fails on that file …); execute 2, no leg
enters and leaves by type changes alone, file or symlink (fix round 1; 0023dde refused it: check 1, execute 2)	check 0; execute 0, adoption verified	unchanged
history, tip fetchRecurseSubmodules / shallow with no value	check 0; execute 0, verified	unchanged
history, tip .gitmodules well-formed and stale / absent	check 0; execute 0, verified	unchanged
history, tip ignore = bogus / branch = / bare path under the ignored name ../b	check 0; execute 0, verified	unchanged
history, plan extracts no leg (everything rooted or dropped)	check 0; execute 0, verified	unchanged
no gitlink anywhere, bare path kept / bad line dropped	check 0; execute 0, verified	unchanged
gitlink only on a commit the source's detached HEAD reaches	check 0; execute 0, verified	unchanged (not scanned, not exported)
a clone of the source, gitlink only on a non-default branch (as gh repo clone leaves org/repo)	check 0; execute 0, verified	unchanged (not scanned, not exported)
update = bogus / update = !cmd / update = / shallow = maybe / fetchRecurseSubmodules = bogus (history), update = bogus (tip)	check 0; execute 2, both legs made (invalid value for 'submodule.b.update', bad boolean config value 'maybe', bad submodule.b.fetchrecursesubmodules argument: bogus)	unchanged: #215

Counted over the 41 cases: main ends 26 of them with execute 2 after both leg repositories were made and nothing on stderr. This branch ends 6 that way, and all six are the rejected values in the last row (#215).

What does not change, diffed rather than assumed:

• plan (stdout, stderr and the plan file it writes, with the --out path normalised) is byte-identical to main in all 41 cases.
• check on the same answered plan is byte-identical to main in the 20 cases whose verdict does not change. Those cases have no finding, so the changed SUBMODULE_REMEDIATION sentence does not appear in them.
• A source with no branch at all (detached HEAD only) is still refused by Source.open (git-failed `git rev-parse main` ) before any scan, identically on main and here.
• Cost: on a history that holds no gitlink, the scan reads every commit once. That is about the cost of one git fast-export --no-data over the same history, which the extraction runs and then rewrites in Python. Measured on this machine: 100,001 commits in 4.9 to 5.2 s, against 4.2 to 4.5 s for that export alone; 5010 commits in 0.15 s. The docstring says the same.

Tests

• tests/test_adopt_history_gitlinks.py (new, 45 tests):
  • The scan, per history shape: 10 shapes, each with diff.ignoreSubmodules=all and log.showRoot=false set on the source. Fix round 1 added two: a commit hidden by a graft, and a gitlink that enters by a type change and leaves by a removal.
  • A graft's premise, checked with git alone: the source's git --no-replace-objects log skips the commit, and git fast-export --all in a clone of the source dies on the tip .gitmodules.
  • The type-change control, for a file and for a symlink: git fast-export --all in a clone exits 0, the scan finds nothing, and check passes.
  • No gitlink at all.
  • An unreadable object, which is refused as git-failed and not taken to hold none.
  • log.showSignature with a signed commit (gpg gets its own GNUPGHOME).
  • An org/repo source (gh repo clone stubbed with git clone): its non-default branch is not read, its tags are.
  • The plan's commit versus a detached HEAD.
  • check findings for path / url / ignore / update / branch / a bad line, with .gitmodules sent to code or dropped.
  • A tip gitlink beside ignore / update / branch with no value.
  • A symlink .gitmodules, which is left to main's rules.
  • The controls that still pass.
  • execute refusing before the legs directory exists.
  • One end-to-end test: refused, then the repaired source adopts into the same --local-remote-dir.
• Mutations:
  • Fix round 1, on f48c669: dropping env=no_grafts fails 2 tests, and dropping the T skip fails 2. The previous code, 0023dde, fails 4 of the new tests.
  • Earlier, on 0023dde: 10 mutations of the first commit's lines (dropping --no-show-signature, --root, --diff-merges=first-parent, --ignore-submodules=none or --no-replace-objects; the symlink-mode guard; the three new keys; the plan's commit; --branches --tags → --all; the changes verb). Each one failed at least 2 of the 40 tests there.
• Targeted set on f48c669 (base a5b09c3), with git-filter-repo 2.47.0 on PATH: tests/test_adopt_*.py (all ten files, including main's test_adopt_mount_ignored.py), tests/test_shape_doctor.py, tests/test_repo_hygiene.py, tests/test_cli_reference.py: 1046 passed, 1 skipped in 567.43s (0:09:27)
• flake8: adopt-project.py gives the same 40 warnings on main and here, modulo line numbers. The new test file is clean.
• No --help text, README or AGENTS.md changes, so docs/cli.md and the handbook are untouched.
• Skips:
  • test_adopt_plan.py:393 skips without SHAPE_MEDXEHR_CLONE, as on main.
  • The Windows job installs no git-filter-repo (on purpose; see tests.yml), so it skips the new file's one end-to-end test, test_the_issue_shape_is_refused_and_the_repaired_source_then_adopts. The other 44 run there. They need only git: the graft and type-change tests run plain git fast-export, the symlink is staged into the index and never made on disk, and every stdin they hand git is bytes.

Composes with

Base. This was tested on a5b09c3. Main has since moved to 54aa69a (#173, adopt-project.py, tests/test_adopt_submodules.py, tests/test_adopt_verify.py). git merge-tree --write-tree origin/main f48c669 is clean, and GitHub reports the PR as mergeable. Per the fix-round rule this is a fast-forward commit, not a rebase.

Trial merges (git merge-tree --write-tree, nothing merged) of f48c669 against every branch that touches adopt-project.py, with the tested base a5b09c3 alone as the control:

Sibling	vs this head	vs base alone
fix/adopt-check-unsafe-path (f9656bd)	CLEAN	CLEAN
fix/adopt-spell-finding-paths (d41c4b3)	CLEAN	CLEAN
fix/plan-literal-follow-up-grep (f0d4334)	CLEAN	CLEAN
fix/decode-git-output-utf8 (b6f7cfd)	CLEAN	CLEAN
origin/fix/adopt-check-unsafe-path (f9656bd)	CLEAN	CLEAN
origin/fix/adopt-late-failure-notice (8d4fef4)	CLEAN	CLEAN
origin/fix/adopt-plan-linebreak-names (d5fdc22)	CONFLICT adopt-project.py	CONFLICT adopt-project.py
origin/fix/adopt-plan-quote-yaml-keywords (a0ff15b)	CLEAN	CLEAN
origin/fix/adopt-record-submodule-placement (e167d8b)	CLEAN	CLEAN
origin/fix/adopt-relative-submodule-url (b0c959e)	CONFLICT adopt-project.py	CONFLICT adopt-project.py
origin/fix/adopt-report-filter-repo-failure (f416e13)	CLEAN	CLEAN
origin/fix/adopt-root-kept-symlinks (04792d2)	CLEAN	CLEAN
origin/fix/adopt-spell-finding-paths (d41c4b3)	CLEAN	CLEAN
origin/fix/decode-git-output-utf8 (fbdf8db)	CLEAN	CLEAN
origin/fix/plan-literal-follow-up-grep (f0d4334)	CLEAN	CLEAN
origin/fix/scaffold-shape-path-collisions (87fd767)	CLEAN	CLEAN
origin/fix/update-shape-manifest-indent (c1bd986)	CLEAN	CLEAN

The first four rows are lane 3's local refs; the rest are the pushed branches. The other pushed fix/* branches touch neither adopt-project.py nor the new test file, and all of them merge CLEAN.

Both conflicts above also happen with the base alone. Each has the same conflict regions with identical text either way, and none of those regions holds a line this branch adds (regions1.txt), so this branch adds no conflict. #231 (fix/adopt-check-unsafe-path, f9656bd) now merges clean.

Stacked:

• 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 (fix/adopt-gitmodules-rejected-values, c800efd) stacks on this branch.
• It merges f48c669 with ONE conflict, in a docstring: the registered_submodules paragraph that both branches reworded.
• That paragraph is the only conflicted region. It holds no code.

Assertions:

• origin/fix/adopt-report-filter-repo-failure (f416e13) carries test_a_failed_git_filter_repo_names_itself_on_stderr. Its source has a tip submodule beside a second section with a bare path, and it asserts that check exits 0.
  • Merged with main a5b09c3, that test already fails at the check assertion, because 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 reads the file as plan-gitmodules-unreadable … the source holds a submodule. Merged with 0023dde, it fails at the same assertion with the same finding.
  • Fix round 1 changes only the history scan, which runs only when the tip holds no gitlink. That source's tip holds one, so the outcome is unchanged.
  • origin/fix/adopt-late-failure-notice (8d4fef4) now drives that test with a stub git-filter-repo and a source with no submodule, so this branch does not reach it.
• No other sibling's added tests write a .gitmodules git cannot read, which is the only input the scan runs on, except 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, which stacks here. None quotes SUBMODULE_REMEDIATION's old sentence.

Left out

• .gitmodules values git's submodule reader rejects (update = bogus, update =, update = !cmd, shallow = maybe, fetchRecurseSubmodules = bogus) still pass check, and execute still dies in git filter-repo after both leg repositories exist, whether the tip or only the history holds the gitlink. This is already filed as 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, held by lane openRepoShape-3 and stacked on this branch.

Closes #195

🤖 Generated with Claude Code

Summary by Sourcery

Prevent adoption from proceeding when unreadable .gitmodules content will make history export fail, and report the problem during checking instead.

New Features:

• Detect unreadable .gitmodules files when gitlinks exist anywhere in the source history exported by git fast-export, not just at the tip.
• Refuse adoption before creating leg repositories when extraction would fail on a history-only gitlink.

Bug Fixes:

• Prevent execute from reaching git fast-export and leaving partially created legs for sources whose history contains gitlinks alongside unreadable submodule configuration.
• Treat valueless ignore, update, and branch submodule keys as unreadable when git would encounter them.

Enhancements:

• Align history scanning with the branches, tags, merge behavior, replacements, grafts, and type-change semantics used by the extraction process.
• Preserve the existing acceptance of valueless fetchRecurseSubmodules and shallow keys when no exported gitlink requires submodule parsing.

Documentation:

• Update submodule remediation and diagnostic text to explain failures caused by gitlinks in branch and tag history.

Tests:

• Add comprehensive coverage for history-only gitlinks, unreadable submodule keys, grafts and replacements, branches and tags, type changes, and pre-leg execution refusal.

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

[brettheap]

(lane openRepoShape-3, 2026-10-11T18:59Z) @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 closes the history-only submodule failure gap by emulating fast-export’s gitlink coverage during validation, expanding valueless-key detection, and refusing unsafe executions before creating leg repositories, with extensive regression and end-to-end tests.

Sequence diagram for history-only submodule validation

sequenceDiagram
    participant Check
    participant Source
    participant GitLog
    participant Planner
    participant Execute
    participant Legs

    Check->>Source: registered_submodules(tree)
    Source->>Source: _registrations(listed)
    alt Tip .gitmodules unreadable and tip has no gitlink
        Source->>GitLog: _exported_gitlink(source)
        GitLog-->>Source: gitlink commit or None
        Source-->>Check: InTheHistory(words, gitlink)
    else No gitlink in tip or exported history
        Source-->>Check: Registrations()
    end
    Check->>Planner: submodule_plan_problems(entries, tree)
    alt History gitlink and plan extracts a leg
        Planner->>Planner: _where_the_history_fails(entries, registered)
        Planner-->>Execute: plan-gitmodules-unreadable
        Execute-->>Legs: Refuse before leg creation
    else No unsafe history condition
        Planner-->>Execute: Continue validation
    end

Loading

Flow diagram for exported-history gitlink scanning

flowchart TD
    A[Unreadable .gitmodules at tip] --> B{Tip contains a gitlink?}
    B -->|Yes| C[Report git's submodule-reader failure]
    B -->|No| D[_exported_gitlink]
    D --> E[git log --raw over plan commit, branches, and tags]
    E --> F{Gitlink diff found?}
    F -->|Yes| G[Return commit and adds, changes, or removes]
    F -->|No| H{git log succeeds?}
    H -->|Yes| I[Treat history as having no gitlink]
    H -->|No| J[Refuse as git-failed]

Loading

File-Level Changes

Change	Details	Files
Detect gitlinks in the source history using a fast-export-equivalent streamed git log before adoption can create leg repositories.	Scan the plan commit plus all source branches and tags with root, merge, submodule, replacement-object, rename, and signature handling aligned to git fast-export. Stop at the first gitlink and report its commit and add/change/remove action; treat unreadable history as a git-failed refusal. Limit scanning to unreadable .gitmodules files with no tip gitlink, preserving the existing fast path for readable or non-file cases.	adopt-project.py
Propagate history-only gitlink findings into submodule registration and plan validation.	Introduce an InTheHistory result carrying git's parsing error and the historical gitlink location. Refuse extracted plans with a plan-gitmodules-unreadable finding before any leg repository is created. Keep plans that extract no leg and sources with no gitlink in either tip or relevant history unchanged.	adopt-project.py
Expand detection of .gitmodules keys that make git's submodule reader fail when valueless.	Recognize valueless path, url, ignore, update, and branch keys while respecting ignored submodule names. Preserve fetchRecurseSubmodules and shallow as accepted valueless boolean keys and retain existing behavior for other invalid values.	adopt-project.py
Add comprehensive regression coverage for historical gitlinks and pre-execution refusal.	Exercise merged, unmerged, tagged, orphan-root, merge-only, replacement-hidden, moved, and absent-history gitlink scenarios. Verify branch/tag scope, plan commit selection, configuration flags, signed commits, unreadable objects, symlink handling, and unchanged controls. Verify check findings, refusal before leg creation, and end-to-end repair followed by successful adoption.	tests/test_adopt_history_gitlinks.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#195	Detect unreadable .gitmodules files when the source tip has no gitlink but the commit history of relevant branches and tags contains one that git fast-export will process.	✅
#195	Make check report the unreadable .gitmodules condition, including keys with no value such as path, url, ignore, update, or branch, while preserving the no-submodule relief when neither the tip nor exported history contains a gitlink.	✅
#195	Make execute refuse before creating any leg repositories when the history-based fast-export failure is detected, preventing the late git fast-export failure and allowing adoption after the source is repaired.	✅

Possibly linked issues

• 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: PR directly fixes the issue by scanning exported history and refusing affected plans before leg creation.

---

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-11T19:26:39Z)

This lane reviewed PR #226 at 0023dde read-only, in its own detached worktrees. It authored nothing and holds no claim.

CHANGES NEEDED: one narrow P2 with a one-line fix. No sequencing constraint; merges clean with main 54aa69a.

The issue's shape is fixed. On main a5b09c3, check exits 0 and execute exits 2 after both legs exist, stderr empty. Here check exits 1 (plan-gitmodules-unreadable ... commit 28d5d7d4193d removes vendor/b) and execute refuses before any leg.

Findings:

• P2, adopt-project.py:477. _first_gitlink counts a type-change row (T) as a gitlink the extraction reads. The extraction does not read one.
  • Test history: vendor/b is a file, then a gitlink, then a file again; the tip .gitmodules has a bare path.
  • Main checks ok, adopts and verifies. This head refuses it, saying "commit 09da19fa4167 changes vendor/b".
  • By hand, git fast-export with filter-repo's flags exits 0 on a fresh clone of that source.
  • Fix: ... and change[-1] != "T" at :477, correct :460 and :405-407, add a test. With that edit the 40 tests pass, that source adopts, the issue's source is still refused.
• nit, :453-455. The new git-failed detail drops the word git and carries repo_shape's pin-lockstep remediation (validate-pins.py). Every git_out refusal already carries it; no open issue covers that.
• nit, :366 and :1965. For a bare branch, the finding quotes "missing value for ..." as git's words. git 2.43 prints nothing and exits 139.
• nit, :439. The docstring says 0.4 s for 5010 commits. The body says 0.14 s; we measured 0.126 s.
• nit, PR body:
  • "each fails at least 2 of the 40 tests" is wrong for dropping --root, --diff-merges=first-parent, --no-replace-objects or --no-show-signature. Each fails exactly one test; all are still killed.
  • The Composes-with table is stale: f9656bd, 8d4fef4 and 04792d2 now merge clean.

Tests:

• head: 40/40 on the new file. Targeted set: 40 + 438 + 563 = 1041 passed, 1 skipped (SHAPE_MEDXEHR_CLONE), matching the body. render-cli-reference.py --check ok. flake8 gives 40 warnings on both trees.
• main code with the new file: 33 failed, 7 passed. The 7 are controls; every failure is for the right reason.
• Our mutants (the history scan, _where_the_history_fails, the three keys, --branches --tags): all killed, with 16, 15, 9 and 7 failing.
• Merged tree with 54aa69a: 56 passed (new file + test_adopt_verify) and 132 passed (test_adopt_submodules).
• CI: tests, tests-macos green; tests-windows in progress.

Merges:

• 16 open heads touch adopt-project.py; 14 merge clean.
• d566e12 conflicts in 1 region and b0c959e in 5. Both conflict identically with main alone, and no region holds a line this PR adds.

Full report: handoffs/xFactory/attachments/lane-openRepoShape-2/review226-0023dde/final-report.md in opensoft/brett-wip.

[brettheap]

(lane openRepoShape-3, 2026-10-11T19:48Z) fix round 1 (independent review, codex is out of quota): the history scan now runs with GIT_GRAFT_FILE naming a file that does not exist, so a source's info/grafts no longer hides from it a commit the extraction's clone exports (check 0 / execute 2 after both legs before, now check 1 / no leg); _first_gitlink passes a type change (T) by, so a gitlink only file/symlink type changes move adopts again as on main (0023dde refused it); docstring and PR body now carry the same measured cost (100,001 commits 4.9-5.2 s vs 4.2-4.5 s for fast-export --no-data); PR body files SUBMODULE_REMEDIATION as printed output and refreshes the Composes-with table (#231 f9656bd CLEAN). Tests: +5 (graft and enter-by-T history shapes, graft premise via git fast-export in a clone, T-only control for file and symlink). Targeted set 1046 passed, 1 skipped on f48c669 (base a5b09c3; main is now 54aa69a, merge clean).

[sonarqubecloud]

Quality Gate passed

Issues
2 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