[brettheap]

Lane: openreposhape-5 (openRepoShape-5)
Claim: #996 (comment)
Claim: #998 (comment)

Goal

Two stops of git's update in the family root's scripts/bootstrap.py still ended family bootstrap ok with the credential advice. Both were found by lane 5's review of #954 (issuecomment-6253384652):

• 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 (checklist candidate 1): git's update ended by a signal. On git 2.43.0, a member's own .gitmodules that gives its code leg a branch with no value crashes submodule--helper (signal 11), and the update exits 139.
• 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 (SHOULD 4): B4 (a member's commit that no branch of its remote holds) with SHAPE_LEGS_TOKEN or SHAPE_LEGS_APP_TOKEN set. the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954 reads B4 from git's trace2 events, and it never traces a run with a token in use.

Both now fail by name, with no advice. Each closes in its own commit:

• da7b14f8 closes 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;
• b2bbb31c closes 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.

Stacked on #954 (#892, lane 4's), at its head fe907c84, and lands after it. The branch is fe907c84 plus these two commits. Until #954 lands, GitHub's diff against main shows #954's changes too.

What changed

#998: a signal (da7b14f8)

• ended_on(returncode) reads the exit code alone, never git's words, as bootstrap.py (family root): after #879, two states still end family bootstrap ok beside git's exit 128: a stray gitlink inside a member's own index, and a member's gitlink at a commit no store holds #892 reads 128:
  • 128 + N, up to 128 + signal.NSIG: a git that git's update ran died of signal N, and the update went on and passed the code up;
  • Python's -N: git itself was killed.
• Read as before:
  • 128 is git's die. It goes to bootstrap.py (family root): after #879, two states still end family bootstrap ok beside git's exit 128: a stray gitlink inside a member's own index, and a member's gitlink at a commit no store holds #892's walk, as it did.
  • A code from 128 + signal.NSIG up (255, which git exits with where a command of its returns -1) numbers no signal. It reads as before.
• Where the run then ends:
  • Where unfetchable names rows, or why git updated none, that line stands. This is the case where git 2.43.0 crashes on the holder's own .gitmodules, and bootstrap.py and validate-family.py: a .gitmodules value git dies on while reading the file fails make bootstrap naming the key, and the family gate names it, so update = None no longer ends family bootstrap ok (#648) #768's rows hold it (mutant S7).
  • Otherwise (a) prints:

      UPDATE KILLED, and not for want of a credential: git's update ended on signal 11 (SIGSEGV, exit 139), which a git it ran died of. Git's own words above say which git and where.
    family bootstrap FAILED: git's update (ended on signal 11)
    

    For -N the line ends (SIGSEGV, exit -11), which killed it. instead.
• No credential advice. credential_advice gives none where a signal ended the update. A fetch git cannot make dies with 128, which ends git's update there. So an update that ends with 128 + N met no failed fetch.

#996: B4 with a token in use (b2bbb31c)

This follows the issue's "Direction (no trace2)".

• When it runs: only after git's update exits 128 with a token in use, and only at the first checkout the walk reaches whose store lacks its recorded commit (commit_held). The walk ends there either way, so this costs two fetches at most.
• What it runs (refetched), the two fetches git's update makes there (run_update_procedure):
  • git fetch origin;
  • then, where the commit is still absent, git fetch origin <commit>.
• How each fetch runs:
  • with the same -c url...insteadOf rewrite in argv as the update;
  • with every GIT_TRACE* variable removed;
  • with GIT_PROTOCOL_FROM_USER=0. This matches what git submodule gives every git it starts. Without it, a plain fetch took the file transport that git's update refused (protocol.file.allow=user), and it brought a commit git's update could not: the token control row found this.
• How it is read:
  • B4 is where the first fetch exits 0 and the commit is still absent after the second.
  • A first fetch that fails is the credential's skip, as now.
  • Where either fetch brings the commit, nothing is said (untold).
• The token appears in no output and in no file:
  • git's update and both fetches run in untraced()'s environment: every GIT_TRACE* variable removed, and trace2's three targets (GIT_TRACE2, GIT_TRACE2_EVENT, GIT_TRACE2_PERF) set to 0.
  • The 0 also turns off a target that the system or global config names (trace2.normalTarget, trace2.perfTarget, trace2.eventTarget). Git reads those config targets wherever the variable is absent or empty.
  • Before this, with GIT_TRACE2_EVENT set by the caller, git's update wrote the token's rewrite into that file. This was measured at the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's head: the probes below, and the control rows failing at base.
  • The token still travels in argv only. No file is written, and what the two fetches print is neither read nor shown.
• The walk's interface: it now takes a Reached predicate (fetch_reached) in place of the trace's work-tree set. With no token, the predicate is the trace's answer, as before. With a token, it is refetched.
• Not done: the issue's optional last paragraph (advice that names the token in use). It is neither small nor clear:
  • the App token and the PAT need different cures (an installation that does not include the repository, against a PAT without contents:read);
  • every token run's advice text would change, while the control rows keep the advice as it is.
  • It is better as its own issue.

Probes, before (#954's head) and after (this head)

Setup:

• git 2.43.0 and Python 3.12.3;
• the family fixture of tests/test_family.py, in the holder with every member checked out;
• bootstrap.py --skip-members;
• a stub gh, GH_TOKEN=bogus, an empty GH_CONFIG_DIR, GIT_SSH_COMMAND=false, GIT_CONFIG_GLOBAL=/dev/null;
• the token is the fake w892-a-token-no-forge-takes.

state	before	after
P3: IRRS's own .gitmodules gives code a bare branch	FETCH INCOMPLETE (git exit 139), error: submodule--helper died of signal 11, the advice, family bootstrap ok, exit 0	the UPDATE KILLED ... signal 11 (SIGSEGV, exit 139) line, FAILED: git's update (ended on signal 11), no advice, exit 1
wrapper git answers (a)'s update with 139	advice, ok, exit 0	UPDATE KILLED ... (SIGSEGV, exit 139) ..., exit 1
wrapper git kills itself with SIGSEGV	(git exit -11), advice, ok, exit 0	UPDATE KILLED ... (SIGSEGV, exit -11), which killed it., exit 1
wrapper git answers 128, every member at its pin	advice, ok	advice, ok (unchanged)
B4 at IRSS with SHAPE_LEGS_TOKEN, then with SHAPE_LEGS_APP_TOKEN; the caller sets GIT_TRACE2_EVENT and GIT_TRACE under TMPDIR	git's own not our ref lines, the advice to set the token, ok, exit 0; the token is in trace2.json	UPDATE STOPPED, and not for want of a credential: git stopped at members/IRSS, whose fetch reached its remote and did not bring <commit>, ..., FAILED: members/IRSS (git stopped at it), exit 1; the token is in no file and no output
control: token set, the file transport refused, IRSS's pin moved on	advice, ok; the token is in trace2.json	advice, ok; the token is in no file

Git's own git submodule update --init --recursive exits 139 in P3 and 128 in each B4 and control state.

Tests

All rows are in tests/test_family_bootstrap_stops_named.py, #954's file. They are written in its style and reuse its helpers (b4, pin_moved_on, moved_by_hand, unpushed, cloning, isolated, said_after_the_fetch), and no assert joins conditions with and. The file now has 24 tests and 37 rows (25 before).

#998:

• test_p3_a_member_s_gitmodules_git_crashes_on_fails_naming_the_signal: P3's state. It is skipped where git's own update does not exit 139: 2.43.1 and later refuse the line and die with 128, as tests/test_doctor_legs_members_next.py skips a crash.
• test_an_update_ended_on_a_signal_fails_naming_it[exit-139] and [sigsegv]: the portable row. A wrapper git first on PATH runs the real git by its absolute path for everything but (a)'s update, and for that one it exits 139, or kills itself with SIGSEGV (core dumps off).
• test_a_code_no_signal_gives_is_read_as_before[exit-128] and [exit-255]: controls; the advice and ok.
• The credential control (no credential, pin moved on, exit 128) is the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's test_the_credential_s_skip_is_as_it_was[pin-moved-on], unchanged. It keeps the advice and ok, and it kills S1.

#996:

• test_with_a_credential_in_use_b4_is_named_and_the_token_is_not[SHAPE_LEGS_APP_TOKEN] and [SHAPE_LEGS_TOKEN]: this is test_with_a_credential_in_use_b4_is_read_as_before turned round. Each asserts:
  • exit 1, the B4 line and the FAILED line, with no advice;
  • the token absent from stdout, stderr and every file under TMPDIR;
  • every trace the person may ask for is on and is written by the walk's own gits: GIT_TRACE, GIT_TRACE2_EVENT and GIT_TRACE_CURL in the environment, and trace2's normal and perf targets in the global config.
• test_with_a_credential_in_use_the_credential_s_skip_is_as_it_was[pin-moved-on] and [b4]: a token set, the file transport refused. Each gives the advice and ok, the token is in no file, and git's own update exits 128.
• test_with_a_credential_in_use_the_two_fetches_are_made_again_untraced: a wrapper git logs the commands bootstrap runs itself, with the token masked. The log reads exactly:
  • the update, with only trace2's three =0;
  • fetch origin, then fetch origin <commit>, each with the token's two -c, GIT_PROTOCOL_FROM_USER=0 and only trace2's three =0.
    Every caller trace is on during this row too.
• test_with_no_credential_the_walk_makes_no_fetch_of_its_own: with no token, the update runs traced into TMPDIR/bootstrap-trace-*, and no fetch is made.
• test_with_a_credential_in_use_a_commit_a_fetch_brings_is_untold[first-fetch] and [second-fetch]: the wrapper answers the update with 128 having fetched nothing. Each gives the advice and ok.
  • [first-fetch]: IRSS's pin is moved to a commit on a branch of its remote, so the first fetch brings it and no second fetch is made.
  • [second-fetch]: the commit is at refs/pins/<commit>, so only the second fetch brings it.

Wrapper rows are skipped on Windows, where a #! script is not run.

A fix to #954's unpushed helper. It now numbers each commit it makes (MADE, a counter for the session). Lane 4's fe907c84 names the commit after the clone's path. But under tmp_path_retention_policy=failed, pytest removes a passed row's directory, and it gives the next row whose name begins with the same 30 characters the same tmp_path.

• In the first 22-file run, [first-fetch] and [second-fetch] both ran in test_with_a_credential_in_use_0 and made one commit in the same second.
• [first-fetch] had pushed that commit to a branch, so [second-fetch] failed.
• The same can befall the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's own rows under that policy, but not under CI's default retention, where each row's directory number is new.

Fails at #954's head. The new file was run against bootstrap.py at 4f97fedb (sha256 8282da7a..., the same bytes at fe907c84):

bootstrap.py at	result
4f97fedb / fe907c84 (#954)	10 failed, 27 passed
da7b14f8 (#998 alone)	7 failed, 30 passed (the #996 rows)
H0 b2bbb31c	37 passed (git 2.43.0, three runs); 36 passed, 1 skipped (git 2.47.1: P3)

• The 10 rows that fail at the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's head:
  • P3;
  • exit-139 and sigsegv;
  • both B4-with-token rows;
  • both token controls, on the token in the caller's trace files;
  • the two-fetches row;
  • both fetch-brings rows.
• The 3 controls that pass there: exit-128, exit-255, and the no-credential row.

Mutants

Each mutant was applied alone to b2bbb31c's bootstrap.py (sha256 e7372f13...; the landing head's file, sha256 50a16751..., is that change plus #1023's hunks, which change none of the functions the mutants change) and run against the stops-named file, and the bytes were restored and checked by sha256 after each. All are killed.

mutant	result
S1 > 128 made >= 128	killed, 23 failed (the 128 controls and every #954 row)
S2 the negative returncode dropped	killed, 1 failed (sigsegv)
S3 the advice still printed	killed, 3 failed
S4 ok still printed (no failure line)	killed, 3 failed
S5 the 128 + signal.NSIG bound dropped	killed, 1 failed (exit-255)
S6 the UPDATE KILLED line dropped	killed, 3 failed
S7 the signal said before unfetchable's rows	killed by #768's rows in test_family_gitmodules_values.py (3 failed: branch-no-value, index-read, head-read)
T1 GIT_TRACE* left in the refetch's environment	killed, 6 failed
T2 the second fetch skipped	killed, 2 failed
T3 a failed first fetch read as B4	killed, 2 failed (both token controls)
T4a the token condition dropped (refetch with no token)	killed, 1 failed (the no-credential row)
T4b traced with the token (#954's R10)	killed, 6 failed
T5 the -c rewrite dropped from the refetch	killed, 2 failed
T6 git's update with a token not untraced	killed, 6 failed
T7 trace2's targets not set to 0	killed, 6 failed (the global config's targets)
T8 GIT_PROTOCOL_FROM_USER=0 dropped	killed, 4 failed
T9 the store not asked after the first fetch	killed, 1 failed ([first-fetch])
T10 the prefix narrowed to GIT_TRACE2	killed, 1 failed (the two-fetches row)
T11 the store not asked after the second fetch	killed, 1 failed ([second-fetch])
R7 (lane 5's, on the refactored predicate) same_place(checkout) in fetched made bool(fetched)	killed, 1 failed

Runs

All runs used /usr/bin/python3 -m pytest -q -p no:cacheprovider -o tmp_path_retention_policy=failed, with one reused basetemp, and this environment:

• EMAIL=service@opensoft.dev;
• a stub gh first on PATH, GH_TOKEN=bogus, an empty GH_CONFIG_DIR;
• GIT_SSH_COMMAND=false, GIT_CONFIG_GLOBAL=/dev/null;
• LANES_* and GIT_ALLOW_PROTOCOL unset.

git	files	result
2.43.0	the 22 files below, at 2a0681ef (this head before the unpushed fix, same bootstrap.py)	1 failed, 1638 passed, 2 skipped, in 11:07; the one failure is [second-fetch], fixed by the unpushed change
2.43.0	H0 b2bbb31c: the stops-named file + test_repo_hygiene.py, test_agents_md_codes.py, test_cli_reference.py, test_no_auto_maintenance.py	265 passed, 2 skipped
2.47.1	this head: test_family_bootstrap_stops_named.py	36 passed, 1 skipped (P3)
2.43.0	after #998 alone: the pinned-copy files and the trio (8 files)	822 passed, 2 skipped

The 22 files:

• the stops-named file;
• the two that grep -l 'family-root/scripts/bootstrap' tests/ names: test_family.py and test_update_shape_kept_helper.py;
• every other file that runs the family root's bootstrap.py: test_family_holder_remedies_compose.py, test_family_holder_bootstrap_texts.py, test_family_bootstrap_gate_order.py, test_family_gitmodules_values.py, test_bootstrap_without_git.py, test_family_unnamed_gitlink.py, test_family_config_appends.py, test_family_member_make_jobserver.py, test_family_siblings_bootstrap_unreadable.py, test_family_head_lost_gitmodules.py, test_family_members_not_a_list.py and test_family_makefile_siblings.py;
• the files that pin the file's text: test_pinned_copy_text.py, test_bootstrap_spelling.py, test_template_text_placeholders.py and test_no_auto_maintenance.py;
• the trio: test_repo_hygiene.py, test_agents_md_codes.py and test_cli_reference.py.

Skips and scope:

• The skips are the environment's: test_no_auto_maintenance.py skips 2 rows because the session began with GIT_CONFIG_GLOBAL set.
• The full suite was not run.

Static checks:

• flake8 finds in bootstrap.py only the three lines it found at base: line 7, the E127 in reason, and the --members-make line in main.
• In the test file it finds only the F811s every fixture-importing file has.
• Both files are ASCII apart from the em dash already in bootstrap.py, with no raw control characters.

Merges

The landing head is 3272d533: the restack 1fb2fbd4 (b2bbb31c's change on #954's squash 8a057215) merged with main eee089ca by gh pr update-branch. The merge is clean, and its tree is git merge-tree --write-tree's own (642527df).

• Of main's commits since 8a057215, only the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 (9e154d87) touches templates/family-root/scripts/. The merge brings exactly the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023's bootstrap.py hunks into this file (patch-id 5563fd8e on both sides). This PR's own change is the same before and after it (patch-id ca48f8b2), and so is the whole PR against main (a2dbbd28).
• validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028 landed as b0babe18 and is in main, so the conflict with the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's hunk measured at b2bbb31c no longer arises.
• rv1045m, lane 5's independent reviewer, delta-checked the merged file READY (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 issuecomment-6295632295). The two patches share no function, and neither changes an environment, argv or exit code that the other reads.

The pinned copy

templates/family-root/scripts/bootstrap.py is in FAMILY_COPIED_VERBATIM, so each holder gets one upstream-changed row for it, as for #954. No Windows or macOS run was made, since CI is Linux only (#597).

Closes #996
Closes #998

🤖 Generated with Claude Code

Summary by Sourcery

Make family bootstrap accurately report Git update failures and credential-authenticated missing commits without exposing tokens.

Bug Fixes:

• Fail family bootstrap when Git's update terminates because of a signal, reporting the signal and exit code without suggesting a credential problem.
• Detect credential-authenticated B4 fetch failures by safely retrying the relevant fetches without tracing, preventing tokens from being exposed while naming the stopped member.

Enhancements:

• Preserve existing behavior for ordinary Git exit codes and credential skips while distinguishing fetches that reach a remote from those blocked by missing credentials.

Tests:

• Add coverage for signal-terminated updates, token-protected B4 cases, credential-skip controls, refetch behavior, trace suppression, and token non-disclosure.

[brettheap]

(lane openRepoShape-5, 2026-10-20T09:45Z) @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-20T09:51:25.374619Z	b2bbb31	Manual request

ℹ️ About Codex in GitHub

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

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

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b2bbb31c13

ℹ️ About Codex in GitHub

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

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

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

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

[chatgpt-codex-connector]

Honor the checkout's configured default remote

When a member or leg is on a branch whose branch.<name>.remote is not origin, recursive submodule update fetches that configured default remote, while both retries here probe origin; Git documents that “the default remote is the remote of the remote-tracking branch of the current branch.” Consequently, if the real upstream fetch fails but origin succeeds without the pin, bootstrap falsely reports B4, while an unreachable origin can preserve the credential advice and successful bootstrap even though the actual upstream was reached and lacks the pin. Retry the initial fetch without an explicit remote and resolve that same default remote for the object-specific fetch.

Useful? React with 👍 / 👎.

[brettheap]

Independent review of #1045 (#998, #996) at b2bbb31c, for lane openRepoShape-5: READY

Both fixes work as the issues ask, and nothing changes where no token is set. I found no MUST and no SHOULD: five NITs and two checklist candidates. Every count in the body that I measured again matches, except one mutant count (NIT 5). I changed no branch, pushed nothing and posted nothing.

Findings, most severe first

NIT 1: three of my mutants survive, all on defensive lines. Each line works today (measured below); no row pins it.

• R1 survives (37 passed). It drops capture_output=True from both fetches in refetched (templates/family-root/scripts/bootstrap.py:655 and :660), so git's output from those fetches reaches bootstrap's own stderr.
  • That capture is what backs the body's "what the two fetches print is neither read nor shown".
  • siblings.py's scrub says git's error text carries "the url it tried ..., token and all".
  • A row that would kill it: in the [b4] token control, git's own update already prints fatal: transport 'file' not allowed twice. Assert it is printed no more often than that. Or have the wrapper echo a marker to stderr on fetch, and assert the marker is absent.
• R2 survives. It changes returncode < GIT_DIED + signal.NSIG (:758) to <=. No row uses exit 193.
• R4 survives. It drops the try/except ValueError in killed_said (:769-772). No row uses a signal Python cannot name, such as 32.

NIT 2: one docstring claim is broader than git's behaviour. credential_advice (bootstrap.py:725-728) and the body say that an update ending 128 + N "met none" — that is, no fetch that failed.

• In git's source (builtin/submodule--helper.c 2.47.1, lines 2700-2704 and 2768-2773), the update keeps the last non-zero code and stops only at 128.
• A member's nested update returns its own code. A leg clone that fails for want of a credential gives 1 (quickstop), and the update goes on.
• So a later crash leaves 139, and the advice is dropped where a credential was in fact missing.
• The run still ends FAILED, never a false ok. I reasoned this from the source and did not run it.

NIT 3: refetched is not quite the same two fetches git makes (bootstrap.py:654 and :659).

• Git's first fetch is a bare git fetch. Its second is git fetch <default remote> <commit>, where the default remote is origin on a detached HEAD and otherwise branch.<b>.remote (source lines 43-72, 2329-2345).
• The writer's version always fetches origin. The two differ only for a member checkout on a branch that tracks another remote.
• Where there is no origin, the first fetch fails, which falls back to the old reading (the advice and ok).

NIT 4: the body's merge table is out of date.

• validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028 has landed as b0babe18, and the head merges clean with it.
• The conflict the body lists exists only against validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028's unmerged branch head aa7f31e3.

NIT 5: mutant T8 is killed by 5 rows, not the body's 4. The extra one is [pin-moved-on] at tests/test_family_bootstrap_stops_named.py:1040. With GIT_PROTOCOL_FROM_USER dropped, the redone fetch takes the file transport and brings the commit, so git's own update afterwards exits 0 instead of 128.

Checked and true

• Head and hashes:

  • The head is b2bbb31c1350…, with first parents b2bbb31c → da7b14f8 → fe907c84.
  • The sha256 of bootstrap.py is 8282da7a… at fe907c84 and e7372f13… at the head, as the body says.

• The new test file against older bootstrap.py bytes:

  • the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's bytes: 10 failed, 27 passed — exactly the body's 10 rows.
  • da7b14f8's bytes: 7 failed, 30 passed — exactly the 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 rows.
  • At the head: 24 test functions (17 before) and 37 rows.

• 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, the exit codes, end to end (a wrapper git, no token):

  git's update	bootstrap
  128, 193 (128+NSIG), 255, 1	the advice and ok, exit 0
  129	signal 1 (SIGHUP, exit 129), FAILED, exit 1
  139	signal 11 (SIGSEGV, exit 139), FAILED, exit 1
  160	signal 32 (exit 160), no name, FAILED, exit 1
  192 (128+NSIG−1)	signal 64 (SIGRTMAX, exit 192), FAILED, exit 1
  killed by SEGV / KILL / TERM	(SIGSEGV, exit -11) / (SIGKILL, exit -9) / (SIGTERM, exit -15), which killed it., exit 1

  • Every signal row gives no advice.
  • A post-checkout hook in a member that exits 130 does not read as a signal: git checkout turns it into 1, and git's update exits 1.

• 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 token in no output and no file (12 rows: both variables, three trace setups, at the head and at the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's head; fake token):

  • The three trace setups were:
    • the six variables GIT_TRACE, GIT_TRACE2, GIT_TRACE2_EVENT, GIT_TRACE2_PERF, GIT_TRACE_CURL and GIT_TRACE_PACKET, set to files;
    • trace2.eventTarget in a scratch GIT_CONFIG_GLOBAL;
    • the same in a scratch GIT_CONFIG_SYSTEM, with GIT_CONFIG_NOSYSTEM removed.
  • At the head: exit 1 with the UPDATE STOPPED … members/IRSS line and the FAILED line. The trace files were written, by the walk's own gits. The token was in no output, and in no file under TMPDIR, HOME or the whole tmp_path.
  • At the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's head: the advice and ok, and the token was written into q-trace2-event.json, q-trace2-normal.txt, q-trace2-perf.txt, q-cfg-event.json and q-sys-event.json.

• The writer's two additions are both right:

  • git 2.43's /usr/lib/git-core/git-submodule:29, and line 29 of 2.47.1's git-submodule.sh, both export GIT_PROTOCOL_FROM_USER=0;
  • running git's update untraced is what closes the measured leak.

• Unchanged with no token, byte for byte against the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's head (after a warm-up run): stdout and stderr were identical in all five states:

  • every member at its pin (exit 0);
  • IRSS's pin moved on, no credential (the advice and ok);
  • B4 (named);
  • B5 (named);
  • a token set with the file transport refused (the advice and ok).

• Cost, from a wrapper's log (a token in use):

  • Update exits 0: no fetch.
  • Both members' pins moved on, transport refused: one fetch, fetch origin, in members/IRRS only.
  • Both members at B4: two fetches, in members/IRRS only, then IRRS is named.
  • Each redone fetch carries the token's two -c, GIT_PROTOCOL_FROM_USER=0 and trace2's three targets set to 0.

• Mutants:

  • The writer's, re-run: S5 1 failed (exit-255); T3 2 failed (both token controls); T8 5 failed (NIT 5).
  • Mine:
    • R3, the walk run on any non-zero code: killed by the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's test_a_stray_git_never_came_to_is_not_said;
    • R5, trace2's targets set to "": killed, 7 failed;
    • R6, the second fetch without the token's rewrite: killed, 2 failed;
    • R1, R2 and R4 survive (NIT 1).

• The unpushed change is correct and harmless:

  • In pytest 9.1.1, _mk_tmp cuts a row's name to 30 characters and numbers its directory one past the highest that exists. Under the failed policy, a passed row's directory is removed at once, so the next row reuses its number.
  • test_with_a_credential_in_use_ is exactly 30 characters, so every 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 row gets test_with_a_credential_in_use_0.
  • The counter makes each commit's message unique in the session, and no test reads the message.
  • It is not reproducible on this host: rows here run more than a second apart, and the counter-dropped variant passed 37.

• The upgrade row:

  • BOOTSTRAP is in FAMILY_COPIED_VERBATIM (scripts/shape_materialize.py:590-592), so a holder gets the same single upstream-changed row the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954 already gives.
  • The only new import is import signal; the repo_shape import list is unchanged.
  • test_pinned_copy_text.py passes.

• Runs at the head, through run9.sh:

  • git 2.43: the stops-named file, test_pinned_copy_text.py and the trio: 294 passed.
  • git 2.43: test_family_gitmodules_values.py, test_family_holder_bootstrap_texts.py and test_bootstrap_without_git.py: 223 passed.
  • git 2.47.1: the stops-named file: 36 passed, 1 skipped (P3: "this git's update exits 128 here").

• Merges (git merge-tree --write-tree):

  merged with	result
  origin/main b0babe18	clean, tree 5c48816e; its bootstrap.py is the head's plus exactly validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028's hunks
  predicted main + the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954, commit f2918070 (dangling object, no ref)	clean, 5c48816e
  the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954 alone against main	clean, 0fde1e34
  the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 5cf60365	clean, 2bfef3d3 (as the body says)
  validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028's branch head aa7f31e3	one conflict in bootstrap.py; fe907c84 against aa7f31e3 conflicts in that file too, so it is the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's own

• Sonar-style checks:

  • Cognitive complexity of the changed functions, all under 15: fetch_members 13, run_update 8, entered 4, credential_advice 3, and 2 or less for ended_on, killed_said, refetched, fetch_reached and untraced.
  • New lines are at most 79 wide in bootstrap.py (the file's maximum stays 82) and at most 78 in the test (its maximum is 79).
  • No assert joins conditions with and; the diff is ASCII with no control characters.
  • flake8 finds in bootstrap.py only lines 7, 959 (E127) and 2038, the same three as at base; in the test, only F811s.

• Docs: no README, AGENTS.md, handbook or cli.md text speaks of traces, signals or the B4-with-token limit.

Could not verify

• git 2.55 (CI's version), Windows and macOS.
• An https remote: the token's rewrite only reaches github.com, and these probes are offline. So I could not check whether git's own error text, or a configured credential.helper storing a url's credentials, would carry the token.
• The writer's 22-file run (1638 passed) and the remaining writer mutants (S1–S4, S6, S7, T1, T2, T4–T7, T9–T11, R7).
• A deterministic reproduction of the same-commit collision the unpushed change fixes.
• NIT 2's state, which I read from git's source and did not run.

Checklist candidates

1. A signal is told only when it is git's last failing code. Measured on 2.43:
   • The state: P3's crash in IRRS plus IRSS's pin moved on, with no credential.
   • Git's update prints submodule--helper died of signal 11, then exits 128 at IRSS.
   • Bootstrap gives the advice and family bootstrap ok, exit 0, although IRRS's legs were never updated.
   • A crash followed by a later exit 1 would read the same way (reasoned from the source).
2. templates/family-root/scripts/siblings.py passes the token's -c rewrite to git in the caller's own environment.
   • It does so for git clone (:964) and git fetch (:997), with no env=.
   • So a caller's GIT_TRACE2_EVENT, or a trace2 target named in the config, writes the token: the leak 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 closes in bootstrap.py.
   • I did not run this on siblings.py. the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954's head was measured writing the token from the same argv shape (above).

Reviewer: rv996, lane 5's independent reviewer, not the writer (w996).

Lane: openreposhape-5 (openRepoShape-5)

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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

[brettheap]

Delta check of #1045's refresh 3272d533 (the merge with main eee089ca, bringing #1023), for lane openRepoShape-5: READY

The merged bootstrap.py keeps both changes' behaviour. The merge is the exact union of the two patches. They share no function, and only the module docstring was edited by both, which merges cleanly. Neither patch changes an environment, argv or exit code that the other reads. A probe ran both paths in one bootstrap run, and it fails against either parent's bytes alone. I found no MUST and no SHOULD, and one NIT. I pushed, posted and filed nothing.

Findings

MUST: none.

SHOULD: none.

NIT 1: the PR body still describes b2bbb31c, not this head.

• The "Merges" table starts from head b2bbb31c (tree ef813192).
  • Its the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 row names 5cf60365, a branch head the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 replaced before landing (it renamed member_make_env to member_make_environment, among other changes). That row's predicted tree 2bfef3d3 holds bootstrap.py blob 920af6f2; the head's blob is 3a8f8e9c.
  • Its validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028 row describes a conflict with an unmerged branch head. validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028 landed as b0babe18, which is in main.
• The mutants are stated against sha256 e7372f13…. The head's bootstrap.py is 50a167510b3951603b6df81c488b33a450afa7d0311e39098ec9a79787d125f8.
• Failure scenario: if the squash message is built from the body, main records a merge table and a digest for bytes that never land. A reader who checks e7372f13 against the landed file finds 50a16751.
• Fix: replace the table with this refresh's facts: head 3272d533, tree 642527df, the merge with eee089ca clean, and the merge bringing exactly the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023's bootstrap.py hunks (the patch-ids below).

Checked and found true

Textual merge

• 3272d533's parents are 1fb2fbd4 and eee089ca, and its tree is merge-tree --write-tree's own 642527df. GitHub's head is still 3272d533.
• The merge base is 8a057215. Of the 8 commits main gained, only the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 (9e154d87) touches templates/family-root/scripts/. No main commit touches the test file.
• Patch-ids are equal on each side of the merge:
  • the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023's bootstrap.py change (8a057215..9e154d87) and what the merge brings into 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's file (1fb2fbd4..3272d533) are both 5563fd8e;
  • 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's bootstrap.py change before and after the merge is ca48f8b2;
  • the whole PR against main (eee089ca..3272d533) and as restacked are both a2dbbd28.
  • The PR still changes exactly 2 files.
• Function level (an AST split of the top-level units):
  • 102 units are unchanged by both. 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 alone changed 18, including fetch_members, run_update, refetched, untraced, ended_on, killed_said, credential_advice, the stopped_below/walked/checkout_stop/entered chain and import signal. the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 alone changed 9, including run_make, member_make_environment, names_a_fifo, reads_fifo and the four new constants.
  • Only the module docstring was changed by both. git merge-file of its three versions equals the merged docstring byte for byte.
  • Line counts add up: 1921 + 163 + 82 = 2166.

Semantic interaction

• Each side's code paths:
  • the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 builds only the environment for make: member_make_environment(make) in run_make and siblings' dispatch, plus a make --version call.
  • 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 builds only the environments for git: untraced() and refetched.
  • Neither PR changes main, run_members, make_program, started or credential.
• Neither script assigns to, pops from or updates os.environ, putenv or unsetenv, so the environment the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 reads in (b) is the one (a) started with.
• untraced() takes out only names that begin with GIT_TRACE and sets trace2's three targets to 0, so MAKEFLAGS and MAKELEVEL pass through. the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 builds no git environment, so it cannot re-add a GIT_TRACE* variable.
• In siblings.py, the merge changes only dispatch's env= and the import list. The token's clone and fetch sites (:608, :1012) are untouched, so rv996's checklist candidate 2 is unchanged and not made worse.
• The member's own bootstrap (templates/assembly-root/scripts/bootstrap.py) uses no token, so the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023's environment, which keeps a caller's GIT_TRACE*, puts no token into any argv.

Pins and upgrade rows

• No tracked file pins a digest of bootstrap.py at the base, at either parent or at the head (git grep for all four).
• The kept-helper row computes its sha256 rather than pinning it.
• siblings.py still takes five names from bootstrap.py, and 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 adds no name to that list.
• family.py and shape_materialize.py: init asks the scaffold's own manifest questions of family.yaml, so init, the scaffold and adopt refuse a validator that exits or answers with something that is not text, and a manifest that is not a mapping, in the same words, and pyflakes finds nothing in either file (#925, #923) #1057's shape_materialize.py and update-shape.py and scripts/bump-leg.py: the three line rewriters find a first-line key after a byte-order mark, as every reader does, and write the mark back as it was (#933) #1050's update-shape.py changes do not touch FAMILY_COPIED_VERBATIM or the guard that checks those names.

Lint

• flake8 finds the same three lines (E127, E501 at 80, E501 at 82) at the base, at both parents and at the head.
• The maximum line width is 82 in all four. The non-ASCII count is the same 4 in all four.

Probe (test_rv1045m_probe.py, 8 rows, with the fake token w892-…, every trace turned on, no --skip-members, a real named pipe, and a fake make answering "GNU Make 4.4.1")

• B4 with a token (both credential variables):
  • the run fails naming B4, with no advice, exit 1;
  • the fake make was asked --version once with no jobserver, and each of the 2 members' makes got MAKEFLAGS byte for byte;
  • the wrapper git logged the update and both redone fetches, each with no GIT_TRACE*, trace2 off, GIT_PROTOCOL_FROM_USER=0 on the fetches, and MAKEFLAGS/MAKELEVEL kept;
  • all four trace files were written;
  • the token was in no output and no file under tmp_path or TMPDIR.
• B4 with a token and a member make that says 4.3: B4 is named and each make gets MAKEFLAGS empty.
• Exit 139, with and without a token: the signal line, FAILED, no advice, and both makes still get the pipe.
• The credential's skip with a token: the advice and ok, exit 0, the pipe handed on, and no token anywhere.
• B4 with no token: told by the trace, with MAKEFLAGS kept beside GIT_TRACE2_EVENT.
• Controls (bytes swapped in a second scratch worktree):
  • 1fb2fbd4's bytes (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 without the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023): 7 failed, 1 passed. Every failure was on the make-calls assert, after 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's own asserts had passed.
  • eee089ca's bytes (main without 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): 6 failed, 2 passed. The token and signal rows exited 0, and the credential's-skip row found the token in trace2-event.json, trace2-normal.txt and trace2-perf.txt.

Runs at 3272d533 through run9.sh (with EMAIL, GIT_SSH_COMMAND=false and GIT_CONFIG_GLOBAL=/dev/null; never more than two at once; never the full suite)

git	files	result
2.43	A: the stops-named file, #1023's two (test_family_member_make_jobserver.py, test_update_shape_kept_helper.py), test_pinned_copy_text.py, the trio	567 passed, 1 skipped (the real-4.4 row: this host's make writes 3,4)
2.43	B: 13 files that run or pin the family bootstrap.py, including test_family.py, test_update_shape.py, the merged-away and landing rows, and test_family_makefile_siblings.py	1176 passed
2.43	C: 9 more files that run the holder's bootstrap	320 passed
2.43	the probe	8 passed
2.47.1	the stops-named file, #1023's two files, the probe	317 passed, 2 skipped (P3, and the real-4.4 row)

Token check: outside the main-only control, the fake token is in no log, no output and no trace file. The only other files holding it are copies of tests/test_family_bootstrap_stops_named.py (where the constant is defined) and my saved copy of the PR body. The main-only control's retained basetemp holds it in 12 trace files, which is the leak that control was meant to show.

Could not verify

• CI's tests check at 3272d533 was still in_progress at 16:17:54Z. tests-git-bash, package, SonarCloud and Sourcery had passed.
• No real GNU make 4.4 was run (4.3 is the only make on this host). The 4.4 path was shown with a real named pipe and a fake make, as the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023 does.
• Not covered: git 2.55, Windows, macOS, and an https remote.
• No committed row runs (a)'s token, B4 or signal paths together with (b) under the named pipe. 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's rows all pass --skip-members, and the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023's rows set no token and never fail (a). Only my probe holds that combination; it is saved below if the writer wants rows from it.

Housekeeping

• Both scratch worktrees (rv1045m-head, rv1045m-ctl) were removed with git worktree remove. The ref my fetch created (refs/remotes/origin/pr1045-rv1045m) was deleted with update-ref -d.
• The shared checkout's HEAD is unchanged at 24769920, with only ?? handoffs.
• The failed controls' basetemps are kept on purpose: /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v110/bt/rv1045m-c1 and /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v110/bt/rv1045m-c2.

Files are in /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v118/rv1045m/:

• /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v118/rv1045m/test_rv1045m_probe.py (the probe)
• /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v118/rv1045m/tools/fnsplit.py (the AST split)
• run logs: run-a-243.log, run-b-243.log, run-c-243.log, run-probe-243.log, run-247.log, run-ctl1-1045only.log, run-ctl2-mainonly.log
• diffs: d1045.diff, d1023.diff, dmerge-bootstrap.diff

Reviewer: rv1045m, lane 5's independent reviewer, not the writer (w996).