[brettheap]

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

Goal

The two texts #1076 (#1056) left in the family root's bootstrap.py say what git does. A member's clone that fails ends git's update before any checkout, where a leg's lets it go on, and a run whose git was itself killed is not said to have gone on. This is #1085, found by rv1076, lane 5's independent review of #1076 (its NITs 1 and 2).

Round 1 was one commit, on main c13c3985 (where #1076 landed); round 2 (below) adds a second. It changes two files: the family root's templates/family-root/scripts/bootstrap.py (docstrings, and one line of killed_said) and tests/test_family_bootstrap_stops_named.py (one row). 2 files, 55 insertions, 14 deletions.

What changed

NIT 1: two docstrings, no behaviour

• credential_advice said "a clone that fails, a member's or a leg's, gives 1, and git's update goes on". That is true of a leg's clone and not of a member's. It now says:
  • a member's fetch that fails ends the update with 128 (as before);
  • a member's clone that fails a second time, git having retried it, ends the update with 1 before any gitlink at that level is checked out (quickstop, git's update_submodules);
  • a leg's clone that fails gives its member's update 1, and git's update goes on (rv996's NIT 2 on the family root's bootstrap.py: git's update ended by a signal fails the run by name, and B4 with a token in use is told from fetches redone without a trace, so the token reaches no file (#998, #996) #1045, kept).
• ended_on said 128 + N is the update's code "where a git it ran died of signal N ... and no gitlink after it failed". A member's git submodule--helper clone that dies of signal N never gives that code: git retries it, and where the retry fails too the update ends in quickstop's 1, even with nothing after it. The docstring now says so, and what that reads as:
  • traced (no token in use): died_in names the signal, since git submodule--helper clone is a git the update ran, and signal_met asks the trace first;
  • with a token in use (the update is not traced, the family root's bootstrap.py: with SHAPE_LEGS_TOKEN or SHAPE_LEGS_APP_TOKEN set, a member's commit no branch of its remote holds (B4) still ends family bootstrap ok, with the advice to set the token that is already set #996): the update's code is 1, which reads as the credential's skip, the advice and ok, the limit credential_advice already says for a signal before a later failure.

NIT 2: killed_said, one line

Where git's trace gave a git's signal (Died(9, 137)) and git's update returned -9 (Python's code for git itself killed), the line said:

a git that git's update ran died of signal 9 (SIGKILL, exit 137), and git's update went on and ended with exit -9. Git's own words above say which git and where.

git's update did not go on and end: it was killed. It now says:

a git that git's update ran died of signal 9 (SIGKILL, exit 137), and git's update was itself killed (exit -9). Git's own words above say which git and where.

Every other line is byte for byte as before. I compared main's and this head's killed_said over 23,814 (Died, returncode) pairs (for each update code from -70 to 299: the update's own ended_on signal, where it gives one, and a trace's signal N = 1 to 64 with code 128 + N), with ended_on itself:

• ended_on differs for 0 codes of -70..299;
• the pairs where the code is the update's own (the 134 codes that give a signal, the family root's bootstrap.py: git's update killed by a signal (exit 129 and above) gives the credential advice and family bootstrap ok #998's texts): 0 differ;
• the pairs where a trace's signal and a positive update code differ: 0;
• 4,480 pairs differ, each with a negative update code and a trace code (70 codes x 64 signals), and each now says "was itself killed (exit -N)".

(A script that loads main's and the head's bootstrap.py from git archive copies; its output is in lane 5's scratch notes, v118/w1085/runs/probe-texts.txt.) The failure line (a git it ran died of signal N) is unchanged, as it is true.

Texts that pin those words

A grep of tests/, README.md, docs/ (the handbook included), AGENTS.md and contracts/ for "went on and ended", "killed_said", "went on", "member's or a leg's", "goes on (rv996", "UPDATE KILLED" and "quickstop" finds the words only in bootstrap.py and in tests/test_family_bootstrap_stops_named.py. There, WENT_ON pins "went on and ended with exit {ended}" with ended 128 and 1 (real runs, a positive code), which is unchanged and still passes. The README, the docs and the handbook say none of them.

The stops-named file's module docstring gains one paragraph for the new row.

What I read in git's source, and what I did not run

I read, and did not run (no network clone, no real gh, no token):

• git 2.47.1: the local build tree of the git the lane's runs use first on PATH (builtin/submodule--helper.c, run-command.c, trace2/tr2_tgt_event.c, usage.c, git-submodule.sh).
• git 2.43.0: upstream's v2.43.0 tag, the same five files (builtin/submodule--helper.c is byte for byte the copy an earlier lane 5 writer kept, w648c on bootstrap.py and validate-family.py: a member no credential would check out fails the family bootstrap, every row's gitlink is asked before any checkout, and --no-members prints the case-variant move (#648) #682, sha256 9383338c...; the other four I fetched as raw files from the tag, a read, not a clone). /usr/bin/git here is Ubuntu's 2.43.0-1ubuntu7.3, which I did not read the patches of.

claim	source (2.47.1 line, 2.43.0 line)
a member's clone is a git child, git submodule--helper clone	prepare_to_clone_next_submodule: child->git_cmd = 1, args submodule--helper clone (:2141-2146, :2053-2058); trace2's child_start writes git first for a git_cmd child (tr2_tgt_event.c :358-361, :359-361)
a child killed by signal N gives 128 + N	wait_or_whine code += 128 (run-command.c :576, :569); finish_command hands it on and writes child_exit (:986-993, :976-983)
that code never reaches the update's own	pp_collect_finished passes it to update_clone_task_finished (:1700-1703, :1690-1693), which answers 0 ("Retry scheduled", :2265) the first time and, the second, sets quickstop and answers 1 ("a second time, aborting", :2276-2280; 2.43.0 :2185-2189)
quickstop ends the update with 1 before any checkout	update_submodules: if (suc.quickstop) { ret = 1; goto cleanup; } (:2737-2740, :2621-2624), before the loop that runs update_submodule for each gitlink
a member's fetch that fails ends it with 128	run_update_procedure: return die_message(...), and die_message returns 128 (usage.c :230-238, :227-235); the loop stops at 128 only (:2772, :2647)
a leg's clone that fails gives its member's update 1 and git's update goes on	the same update_submodules runs in the member's own git submodule--helper update (update_submodule: ret = run_command(&cp), :2700, :2584, which discards die_message's 128 and returns the member's 1); the holder's loop keeps going on any code but 128
git submodule update passes the helper's code on	git-submodule.sh: the helper is cmd_update's last command, no || exit (:380-403, :341-363)

Two offline probes, local paths only (no network, no gh, no token, git config never run, GIT_CONFIG_GLOBAL=/dev/null; lane 5's scratch notes, v118/w1085/probe/quickstop.sh, with its outputs out243.txt and out247.txt), on git 2.43.0 and 2.47.1, give the same on both:

state	git's update	what is in the work trees
holder with members/A, members/B (a url that is not there), members/C	exit 1, Failed to clone 'members/B'. Retry scheduled, then a second time, aborting	A and C cloned, none checked out (.git only), B empty
holder with members/M (its leg legs/L2 has a url that is not there) and members/N after it	exit 1, Failed to clone 'legs/L2'. Retry scheduled	M and N both checked out (git's update went on past M's 1); M's leg L1 cloned, not checked out

Not run:

• bootstrap.py itself over a member's clone killed by a signal. Git's update over one was measured in round 2 below (rv1088's probe, which I ran again), and the trace's child_start argv for it is from tr2_tgt_event.c;
• git 2.43.0's remote helper or any network clone;
• Windows and macOS (CI is Linux only, ci: run the test suite on Linux only #597).

One thing I read and left alone, as the brief says every other line stays byte for byte: where the trace names a signal and the update's code is a positive 1 from quickstop, killed_said still says "git's update went on and ended with exit 1". It ended there rather than went on. It is a wording nit of the same kind, not a behaviour; I did not change it here.

The row that fails on main, and passes with the change

test_an_update_itself_killed_after_a_signal_is_not_said_to_go_on (new; 48 rows before, 49 after). It loads the family root's bootstrap.py as a module (loaded, from tests/test_family_holder_bootstrap_texts.py, which the stops-named file already imports from) and calls killed_said(Died(9, 137), -9), as signal_met hands it its arguments. No run here reaches that line short of the OOM killer taking a checkout and later the top git. One assert, said == KILLED_AFTER.format(...), no and or or.

Main's bootstrap.py bytes (sha256 f1c156e2...) against this branch's 49-row file, git 2.43.0: 1 failed, 48 passed. The failure, from v118/w1085/runs/mut-mainbytes.log:

E         - s update was itself killed (exit -9). Git's own words above say which git and where.
E         + s update went on and ended with exit -9. Git's own words above say which git and where.

The other 48 rows pass on main's bytes (the old WENT_ON rows say only positive codes). At this head it passes.

Mutants

Each applied alone to the change's bootstrap.py (a script replaces one exact string and asserts it occurs once), the stops-named file run on git 2.43.0 (/usr/bin/git) through run9.sh, the file put back from the head's bytes and its sha256 checked (a52483c8...) after each. Lane 5's scratch notes, v118/w1085/runs/mutants-summary.txt.

	mutant	result
M1	the new branch dropped (the ternary replaced by the old wording alone)	killed: 1 failed (the new row), 48 passed
M2	the negative test inverted (returncode > 0)	killed: 7 failed, 42 passed: the new row and the six that say "went on" (both killed-checkout rows, P3, the both-named row, two-members, two-legs)
M3	the old "went on and ended with exit N" kept for negative codes (the branch's text is the old wording, its test kept)	killed: 1 failed (the new row)
M4	"went on" kept beside the new words (went on and was itself killed (exit -9))	killed: 1 failed (the new row)
M5	the test asks the trace's code, not the update's (died.code < 0)	killed: 1 failed (the new row)
M6	the code not said (was itself killed)	killed: 1 failed (the new row)

M1 and M3 behave the same (both give the old wording for a negative code) and differ in the text of the mutation only.

Runs

All through run9.sh (the real gh replaced by a stub, GH_TOKEN a fake, every LANES_* variable cleared, EMAIL=service@opensoft.dev, GIT_SSH_COMMAND=false, GIT_CONFIG_GLOBAL=/dev/null), at most two at once, never the full suite. At this head, bootstrap.py sha256 a52483c8..., the test file 2fb6b4dd....

run	git	result
tests/test_family_bootstrap_stops_named.py (49 rows)	2.43.0 (/usr/bin/git)	49 passed
the same	2.47.1 (git --version printed git version 2.47.1; the lane's local 2.47.1 build first on PATH)	47 passed, 2 skipped (the two P3 rows: that git exits 128 there, where 2.43.0's crashes with 139)
tests/test_family.py, tests/test_update_shape_kept_helper.py (the two files grep -l 'family-root/scripts/bootstrap' tests/*.py gives) and tests/test_family_holder_bootstrap_texts.py	2.43.0	328 passed
tests/test_pinned_copy_text.py and the trio (test_repo_hygiene.py, test_agents_md_codes.py, test_cli_reference.py), with test_template_text_placeholders.py	2.43.0	399 passed
the six mutants and main's bytes	2.43.0	see above

flake8 on bootstrap.py shows the 3 findings main has (E501 at line 7 and 2327, E127 at 1168), and on the test file the same 120 F811 findings main's file has (the fixture imports). New lines are 79 characters at most, ASCII only.

Merges

git merge-tree --write-tree of this head 88af1b7b8 against origin/main, fetched again with -c gc.auto=0 -c maintenance.auto=false just before the push (it moved once while this was open: 06cbd4789, #1081, one test file), and against each open PR that touches bootstrap.py, read with gh pr list --state open --json number,headRefName,files (9 open; #1062 touches the family root's bootstrap.py; #1075's files are siblings.py and two test files; #1087, new since the first read, touches neither):

against	result
origin/main 06cbd4789 (one commit past this branch's base c13c3985; it touches only tests/test_doctor_gitlink_repairs.py)	clean, tree a10ffa31c (against c13c3985 the merge was this head's own tree, deeab934f)
#1062 fix/1040-windows-start-errors 957ba0386 (touches bootstrap.py, in git_not_started)	clean, tree 46f25219c; the merged family root bootstrap.py parses, and holds died_in, quickstop, "was itself killed (exit" and #1062's 4551
#1075 fix/1055-siblings-untraced 041f7831b (lane 5's: siblings.py)	clean, tree 02b01b276; the merged siblings.py imports REWRITE_TARGETS, credential, member_make_environment, member_path, members_of and untraced from bootstrap.py, and all six are defined at module level in the merged bootstrap.py

None of the other open PRs touches bootstrap.py or the stops-named file. This change defines and renames nothing a caller imports.

The pinned copy

templates/family-root/scripts/bootstrap.py is in FAMILY_COPIED_VERBATIM, so each holder takes one upstream-changed row for it, as for #1045 and #1076. Nothing else is pinned. No Windows or macOS run was made.

Round 2 (rv1088's NIT 1, head 26f49d850)

rv1088 (#1088 issuecomment-6314332205) found the review READY with one NIT: the sentence this PR added to ended_on said git's update retries a killed member clone, and it does not always. This round is one commit on top of 88af1b7b8 (the branch was not rebased), docstring only, one file (templates/family-root/scripts/bootstrap.py, +8 -4). No behaviour changes, and killed_said's "went on and ended with exit 1" line is left as it is (rv1088 found it true).

Measured, offline, on git 2.43.0 and 2.47.1 (rv1088's killprobe.sh: a remote helper that SIGKILLs the git submodule--helper clone above it; I ran both modes again on both gits and got the same):

the member's clone	git's update	work trees
killed on both attempts	exit 1: Retry scheduled, then a second time, aborting	A and C hold .git only, B empty: nothing checked out
killed once, its own git clone child left running (it writes members/B/.git)	exit 0: Retry scheduled, then BUG: submodule considered for cloning, doesn't need cloning any more?, no second attempt	A, B and C all checked out

ended_on now says: git's update retries a killed member clone where it left no .git at the member's path, and where the retry fails too ends in quickstop's 1 before any gitlink at that level is checked out; where its own git clone lived on and wrote that .git, git retries nothing and goes on, and exits 0 with every gitlink checked out (measured, git 2.43.0 and 2.47.1). "Read, not run" is now "measured". signal_met already says nothing for an exit of 0, and credential_advice's "fails a second time, git having retried it" stays true, so neither changes.

No other text pins those words: a grep of tests/, README.md, docs/ (the handbook included) and AGENTS.md for "retries it", "doesn't need cloning", "never gives that code" and "quickstop" finds them only in bootstrap.py, and the round-1 words "(read in git 2.43.0's and 2.47.1's submodule--helper.c, not run)" are gone everywhere. "not run" alone appears in other files only in unrelated senses (rv1088's re-check). flake8 shows the same 3 findings as before (the lines moved by 4).

Runs at this head, through run9.sh with EMAIL=service@opensoft.dev (GIT_SSH_COMMAND=false and GIT_CONFIG_GLOBAL=/dev/null set by the runner), the stops-named file and the trio at the same time:

run	git	result
tests/test_family_bootstrap_stops_named.py	2.43.0 (/usr/bin/git)	49 passed
tests/test_repo_hygiene.py, tests/test_agents_md_codes.py, tests/test_cli_reference.py	2.43.0	170 passed
tests/test_family_bootstrap_stops_named.py (git --version printed git version 2.47.1, the lane's 2.47.1 build first on PATH)	2.47.1	47 passed, 2 skipped (the two P3 rows, as before)

Merges, git merge-tree --write-tree of this head against origin/main re-fetched with -c gc.auto=0 -c maintenance.auto=false:

against	result
origin/main 16f9a0e81 (#1087 and the commits since this branch's base; #1062 has landed, so main's bootstrap.py moved)	clean, tree b3b454168; the merged family root bootstrap.py parses and holds died_in, git_not_started, "was itself killed (exit" and the new BUG sentence
#1075 fix/1055-siblings-untraced 962ae43c1 (its head moved since round 1)	clean, tree a4c72197c; the merged siblings.py imports REWRITE_TARGETS, credential, member_make_environment, member_path, members_of and untraced from bootstrap.py, and all six are defined in the merged bootstrap.py

The other open PRs touch neither bootstrap.py nor the stops-named file. #1088 stays a draft.

Closes #1085

🤖 Generated with Claude Code

Summary by Sourcery

Correct family bootstrap diagnostics to accurately report Git update termination and continuation behavior.

Bug Fixes:

• Correct bootstrap status messages so member clone failures and killed updates accurately describe whether Git continued, retried, or stopped before checkout.

Enhancements:

• Clarify bootstrap documentation for Git’s handling of failed or signal-terminated member and leg clones, including credential and signal interpretation.
• Add coverage ensuring an update killed after a traced Git signal is not reported as having continued.

Tests:

• Add a regression test for the corrected killed-update message.

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

[sourcery-ai]

Reviewer's Guide

Refines family bootstrap’s failure wording to match Git’s submodule update semantics, especially member clone quick-stop behavior and updates killed by signals, with a regression test for the corrected killed_said message.

Sequence diagram for Git submodule clone failure handling

sequenceDiagram
    participant Update as Git update
    participant Clone as git submodule--helper clone
    participant Checkout as Gitlink checkout

    Update->>Clone: clone member
    Clone-->>Update: failure 128 + N
    Update->>Clone: retry clone
    Clone-->>Update: failure 128 + N
    Update->>Update: quickstop returns 1
    Note over Update,Checkout: No gitlink at that level is checked out

Loading

Sequence diagram for leg clone failure continuation

sequenceDiagram
    participant Update as Git update
    participant Member as Member update
    participant Leg as Leg clone
    participant Next as Next gitlink

    Update->>Member: update member
    Member->>Leg: clone leg
    Leg-->>Member: failure
    Member-->>Update: return 1
    Update->>Next: continue update
    Next-->>Update: checkout succeeds

Loading

Flow diagram for killed_said message selection

flowchart TD
    A[Trace signal differs from update return code] --> B{returncode < 0?}
    B -->|Yes| C[Say update was itself killed]
    B -->|No| D[Say update went on and ended with exit code]
    E[Trace signal equals update return code] --> F{returncode < 0?}
    F -->|Yes| G[Say update ended on the signal]
    F -->|No| H[Say update ended on the signal from a child git]

Loading

File-Level Changes

Change	Details	Files
Corrected bootstrap diagnostics and documentation to distinguish member clone quick-stops, leg clone continuation, and updates killed by signals.	Updated credential advice to document member clone retries ending with code 1 before checkout while leg failures let the parent update continue. Clarified ended_on behavior for signal-killed member clones, including traced and credential-token cases. Changed killed_said to report negative update codes as the update being killed rather than continuing. Added focused regression coverage for a traced signal followed by a negatively terminated update.	templates/family-root/scripts/bootstrap.py tests/test_family_bootstrap_stops_named.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#1085	Correct credential_advice and ended_on documentation to describe how failed or signal-killed member clones end the update, distinguish that from a failed leg clone, and explain how the result is reported with and without a token.	✅
#1085	Change killed_said so a negative update return code says the update was itself killed rather than implying it went on, and add a regression test that directly exercises that case.	✅

---

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-5, 2026-10-20T23:26Z) @codex review

[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-20T23:29:56.324357Z	88af1b7	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: Didn't find any major issues. What shall we delve into next?

Reviewed commit: 88af1b7b83

ℹ️ 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".

[brettheap]

Independent review of #1088 (#1085) at 88af1b7b, for lane openRepoShape-5: READY

The head reads 88af1b7b832ec3467f4ab6deec280b2ba95ab0fe: one commit on c13c3985, two files, 55 insertions and 14 deletions. It is READY because the only finding is a NIT in a docstring. All runs went through run9.sh, never more than two at once. I made no pushes, posts or filings.

Findings

NIT 1: ended_on's new sentence says git always retries a killed member clone, and it does not. (templates/family-root/scripts/bootstrap.py:925-930)

• The text: "git's update retries it, and where the retry fails too ends in quickstop's 1, before any gitlink at that level is checked out ... (read in git 2.43.0's and 2.47.1's submodule--helper.c, not run)".
• I ran it on both gits, offline, with a remote helper that SIGKILLs the git submodule--helper clone above it ($Q/v118/rv1088/tools/killprobe.sh).
• Killed on both attempts: "Retry scheduled", then C is cloned, then "a second time, aborting", exit 1, and nothing is checked out. The sentence is true here.
• Killed only, with the helper's own git clone child left running:
  • The orphaned clone writes members/B/.git, so git prints BUG: submodule considered for cloning, doesn't need cloning any more? and retries nothing.
  • No quickstop follows. The update checks out A, B and C and exits 0, the same on 2.43.0 and 2.47.1.
  • So "retries it" is false whenever the signal reaches the helper but not its git clone, as a kill -9 <pid> of that one process does.
• Effect: none on behaviour. signal_met already says nothing for an exit of 0, and the credential_advice sentence is worded "fails a second time, git having retried it", so it stays true.
• Suggested wording: "git's update retries it where it left no .git at the member's path, and where the retry fails too ends in quickstop's 1 ...; where its own git clone lived on and wrote that .git, git retries nothing and goes on (measured, 2.43.0 and 2.47.1: every gitlink checked out, exit 0)." "Not run" can then become "measured".

The writer's leftover is true, so it needs no change here or in a follow-up. For a trace signal with quickstop's positive 1, the line is "git's update went on and ended with exit 1". In my run, after B's first SIGKILL git did go on: it cloned C and retried B, and only then aborted with exit 1. The line makes no claim about checkouts. A follow-up could add "and checked nothing out", but that is optional polish.

Checked and true

1. The docstrings, against git's source

• 2.47.1 came from $Q/v115/w764/dl/git-2.47.1.tar.gz, extracted to $Q/v118/rv1088/src247. 2.43.0 came from the writer's copies; the helper's sha256 is 9383338c…, as the body says.
• Every claim holds in both versions:
  • quickstop is set in update_clone_task_finished and update_clone_start_failure;
  • update_submodules checks if (suc.quickstop) { ret = 1; goto cleanup; } before the checkout loop;
  • the loop stops only on 128;
  • the recursion returns ret = run_command(&cp);
  • wait_or_whine gives code += 128, and finish_command passes it to trace2_child_exit;
  • trace2's child_start prepends git for a git_cmd child;
  • die_message returns 128;
  • git-submodule.sh ends on the helper, so its code is passed on.
• All 17 cited line ranges read as the body says.

2. The writer's two probes, re-run on 2.43.0 and 2.47.1, give the same on both

• A member's clone that fails: exit 1, then "Retry scheduled" and "a second time, aborting". A and C hold .git only, and B is empty.
• A leg's clone that fails: exit 1. M and N are both checked out, and L1 holds .git only.

3. Traced, died_in names the killed member clone

• On both gits the trace's child_start argv is ["git","submodule--helper","clone",…], and traced_in gives Died(9, 137).
• With a token in use, the code path reads as the docstring says: ended_on(1) gives None, B is the credential's skip, then the advice, and no failure lines. I read this; I did not run bootstrap.

4. killed_said against main

• AST: with docstrings stripped, killed_said is the only one of 139 top-level nodes that differs.
• Wide grid:
  • 626,703 pairs: return codes -300 to 599, signals 0 to 99, and seven code shapes.
  • 179,001 differ, which is exactly the set with a negative code that is not the trace's own.
  • Each differs only in "went on and ended with exit N", which becomes "was itself killed (exit N)".
• The writer's grid, reproduced:
  • 23,814 pairs, of which 4,480 differ;
  • the 134 codes that give the update's own signal: 0 differ;
  • a trace's signal with a code of 0 or more: 0 differ.
• Other functions: ended_on (-1000 to 999), died_of and signal_met (3,600 cases) differ 0 times. told_past differs in 320 of 1,574 cases, all with a negative code.

5. The new row

• It has one == assert, with no and or or, in the file's style.
• With current main 2a119f28's bootstrap.py (sha256 88639e44…): 1 failed (the new row), 48 passed, with the same diff the writer quotes. At the head it passes.

6. Mutants, each applied alone, the whole stops-named file on 2.43

• M1, M2 and M3 have the same bytes as the writer's (sha256 c9ad7c1f, 534e4c28, b4c68d57).

mutant	result
M1: the new branch dropped	1 failed (the new row)
M2: the negative test inverted	7 failed: the new row, both killed-checkout rows, P3, the both-named row, two-members, two-legs
M3: the old wording kept for negative codes	1 failed
R2: exit {died.code} in the killed text	1 failed
R3: exit {-returncode}	1 failed
R4: != changed to >	2 failed (two-members, two-legs)
R5: the went-on text says died.code	6 failed
R1: returncode <= 0	survives (49 passed)

R1 is equivalent: killed_said is reached only through signal_met, which returns None for an exit of 0.

7. Runs at the head

run	git	result
stops-named file	2.43.0 (/usr/bin/git)	49 passed
test_family.py, test_update_shape_kept_helper.py, test_family_holder_bootstrap_texts.py	2.43.0	328 passed
test_pinned_copy_text.py and the trio	2.43.0	257 passed
stops-named file	2.47.1 ($Q/v115/w764/git247/bin/git; git --version printed git version 2.47.1)	47 passed, 2 skipped (the P3 rows at :837 and :1330)

8. Merges

• Re-fetched origin/main 2a119f281c15 (validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot start for a reason other than 193 that names no file (winerror 216, 1260, 11, or 188-202) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1 (#1040) #1062 has landed): clean, tree 35d0c95c. The merged bootstrap.py differs from main's by exactly the PR's 39 lines, and it parses.
• the family root's siblings.py: with a token in use, the clone and the fetch that carry it run in bootstrap.py's untraced() environment, so make siblings and family.py siblings write the token to no trace the caller asks git for (#1055) #1075 at 041f7831b: this is still its head; the fetch at about 10:48Z and a later gh pr list both show it. Clean, tree 02b01b27. The merged bootstrap.py is byte for byte the head's. All six of siblings.py's imports are defined at the top of the merged bootstrap.py: REWRITE_TARGETS, credential, member_make_environment, member_path, members_of and untraced. The merged siblings.py also loads.
• The body's own trees reproduce: 06cbd478 gives a10ffa31, c13c3985 gives deeab934 (the head's own tree), and validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot start for a reason other than 193 that names no file (winerror 216, 1260, 11, or 188-202) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1 (#1040) #1062's 957ba038 gives 46f25219.
• 6 PRs are open now; besides the family root's bootstrap.py: credential_advice and ended_on say a member's failed clone ends git's update with 1 before any checkout but a leg's lets it go on, and killed_said says git's update was itself killed, not that it went on (#1085) #1088 itself, only the family root's siblings.py: with a token in use, the clone and the fetch that carry it run in bootstrap.py's untraced() environment, so make siblings and family.py siblings write the token to no trace the caller asks git for (#1055) #1075 touches the family root's scripts.

9. Sonar-style checks and the pinned copy

• killed_said's cognitive complexity is 5 (main's is 3), against 15.
• No duplicated blocks.
• Added lines are at most 76 characters, and ASCII only.
• flake8 gives the same on head and base: 3 findings in bootstrap.py, 120 F811 in the test file.
• No import changes.
• bootstrap.py is in FAMILY_COPIED_VERBATIM (via BOOTSTRAP).
• The phrases appear only in bootstrap.py and the stops-named file: none in README, docs/ or the handbook.

10. Title and body

• The title is 249 characters and true.
• Closes #1085 is the only closing keyword, and closingIssuesReferences lists only templates/family-root/scripts/bootstrap.py: credential_advice says a member's failed clone lets git's update go on, which only a leg's does, and killed_said says the update "went on" where git itself was killed (rv1076's NITs 1 and 2 on #1076) #1085.
• Body numbers I reproduced:
  • 2 files, 55 insertions and 14 deletions;
  • 23,814, 4,480, 134, and 70 x 64;
  • 48 rows before and 49 after;
  • 1 failed and 48 passed on main's bytes;
  • M1, M2 and M3;
  • the 2.47.1 run's 47 passed and 2 skipped;
  • the flake8 counts (3 and 120);
  • sha256 f1c156e2, a52483c8, 2fb6b4dd and 9383338c;
  • every merge tree.

Could not verify

• Not re-run: M4, M5 and M6. The body's "399 passed" included test_template_text_placeholders.py, which I did not run; I ran 4 of its 5 files, 257 passed. "9 open PRs" was true at the writer's time; there are 6 now.
• The 2.43.0 sources: I did not check where the writer's copies of the four files other than the helper came from, and I did not read the patches in Ubuntu's 2.43.0.
• Not run: a token-in-use bootstrap run over a killed clone (I only read the code); CI's git 2.55.0; Windows and macOS.

Checklist candidates

1. Pre-existing, outside this PR, read and not run through bootstrap.
   • Where a member's clone fails twice, git checks out no member at that level. The probes show A and C with .git only, on both gits.
   • But checked_out (bootstrap.py:396) asks only whether the mount holds a .git, so (a) counts those members as checked out. It names only the failed member, as the credential's skip or with its reason.
   • The likely case is a private member with no token: the advice and "What did arrive is bootstrapped below", over members whose work trees are empty.
   • It needs a reproduction before anyone files it.
2. Optional polish: the quickstop 1 line could also say "and checked nothing out".

Scratch I leave

• Notes, tools, logs, probes and the extracted 2.47.1 files are in /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v118/rv1088/:
  • logs are in runs/, including grid.txt;
  • the probe outputs are in probe/: kfail243, kfail247, kserve243, kserve247, run243 and run247.
• Basetemps are in /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v110/bt/: rv1088-a, rv1088-b, rv1088-mutA and rv1088-mutB.
• The three worktrees rv1088-head, rv1088-mutA and rv1088-mutB are removed with git worktree remove. The refs refs/l5rv/rv1088-pr1088 and refs/l5rv/rv1088-b1075 are deleted.
• The shared checkout shows only ?? handoffs.
• Nothing of mine is running.

[brettheap]

Re-check of #1088 (#1085) at 26f49d85, for lane openRepoShape-5: READY

Round 2 fixes the NIT from round 1: the sentence now says what I measured, on both gits. A third probe also found that the "exits 0" case is not a race. The one new finding is a NIT in the PR body. I re-checked as a delta from 88af1b7b, read-only and offline.

Findings

• NIT, PR body only, Round 2 section.
  • Claim: a grep for "retries it", "not run", "doesn't need cloning", "never gives that code" and "quickstop" "finds them only in bootstrap.py".
  • For "not run" that is false: the phrase is in 56 files under tests/, README.md, docs/ and AGENTS.md. Every one of those uses is unrelated ("does not run", or "read, not run" about other things). The only hit in the stops-named file is its line 845, about Windows not running a shell script.
  • The four other phrases are found only in bootstrap.py, and the old wording "(read in git 2.43.0's and 2.47.1's submodule--helper.c, not run)" is gone everywhere.
  • So no text pins the old words; only the body's sentence is too broad. It can be left as it is.

Checked and true

• The delta
  • It is one commit on 88af1b7b8 (no rebase), authored Brett Heap <service@opensoft.dev>, changing only templates/family-root/scripts/bootstrap.py, +8 -4.
  • With docstrings stripped, the code is the same as round 1's, so nothing else changed.
  • Added lines are at most 74 characters and ASCII only.
  • flake8 gives the same 3 findings, 4 lines lower (7, 1172, 2331).
• The sentence matches my measurements on both gits. Measured offline with my probe at $Q/v118/rv1088/tools/killprobe.sh, on git 2.43.0 and 2.47.1:
  • Clone killed on both attempts: git retries, then quickstop, exit 1, nothing checked out.
  • Clone killed once, its own git clone left running: the BUG: submodule considered for cloning, doesn't need cloning any more? line, no retry, exit 0, and A, B and C all checked out.
• The "exits 0" case is not a race. I ran it again with the orphaned clone held back 4 seconds before it served (r2/kslow243, r2/kslow247). The result was the same on both gits: exit 0, every gitlink checked out. Git's trace shows why:
  • the killed helper's child_exit 137 came about 4.2 s after its child_start;
  • so git reaps the helper only after the orphan, which holds the helper's stderr pipe, has finished.
• Runs at 26f49d85, through run9.sh on 2.43.0: the stops-named file, test_pinned_copy_text.py and the trio, 306 passed and 0 failed. That matches the body's 49 for the stops-named file plus 170 for the trio, with 87 for the pinned-copy file.
• Merge with main 6da757cbe9a4: git merge-tree --write-tree 6da757cb 26f49d85 is clean, tree a74ae589.
  • The merged bootstrap.py differs from main's by exactly the PR's 43 diff lines.
  • the family root's siblings.py: with a token in use, the clone and the fetch that carry it run in bootstrap.py's untraced() environment, so make siblings and family.py siblings write the token to no trace the caller asks git for (#1055) #1075 has landed on main (7e00834cf). All six of the merged siblings.py's imports from bootstrap.py are defined there.
• The body's Round 2 numbers I reproduced
  • +8 -4, one file;
  • both probe rows of its table;
  • the merge with 16f9a0e81: tree b3b45416;
  • the merge with the family root's siblings.py: with a token in use, the clone and the fetch that carry it run in bootstrap.py's untraced() environment, so make siblings and family.py siblings write the token to no trace the caller asks git for (#1055) #1075's 962ae43c1: tree a4c72197;
  • the 3 flake8 findings;
  • the PR is a draft, Closes #1085 is its only closing keyword, and the title is 249 characters.

Could not verify

• The writer's 2.47.1 run (47 passed, 2 skipped): I ran only on 2.43 this round.
• The writer's own re-runs of my probe: I re-ran the probe myself instead.
• CI's git 2.55.0, Windows and macOS.
• The case where the orphaned clone is killed too, which would leave a broken .git. The sentence does not claim it.

Scratch

• Round 2 notes, logs and probes are in /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v118/rv1088/r2/. I added a delay option (RVX_SLEEP) to my own tools/bin/git-remote-rvx.
• The basetemp /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v110/bt/rv1088-a was reused.
• I removed the worktree rv1088-r2 with git worktree remove and deleted the ref refs/l5rv/rv1088-r2. The shared checkout shows only ?? handoffs.
• Nothing of mine is running. The run9.sh runs still on the host belong to rv1091, w1017 and w904.

(Posted by lane openRepoShape-5's coordinator. rv1088 is lane 5's independent opus reviewer; it wrote none of #1088. Its body NIT is fixed in the body's Round 2 section. #1088 stays a DRAFT until the v1.2.0 tag.)

Lane: openreposhape-5 (openRepoShape-5)

[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 1 hour and 2 minutes by commenting @sourcery-ai review. Upgrade to get a review now.