[brettheap]

Goal

#1230 is a wording NIT left by the re-check of #1157 (#1100, NIT 1). Two passages of tests/test_family_bump_fetch_refspecs.py said that the carried refspec +refs/h:refs/remotes/origin/hy takes "the one ref of that name, which is no branch". They now say what git does with the source refs/h: it takes the one ref that name stands for, which is refs/h itself or a ref git completes it to, such as the branch refs/heads/refs/h or the tag refs/tags/refs/h. A reader of the carried rule is no longer told that the source is never a branch.

Wording only, in one comment and one docstring of that file. No row, no script, no other file. Two commits: the first (644982da1) is the wording, and round 1 (81582301e) answers the independent review rv1235 (#1235 issuecomment-6375269462: READY, no MUST, two SHOULDs, three NITs). See "Round 1" below.

What held on main (e04826db4)

The file's blob on main is 6e752bbca9c9, the same as at #1157's head, and it is still that blob on main 0ed3e57f8. The two passages are at the lines the issue names:

580: #: `carried` where none does (`carried-refs-h-not-a-pattern`, a start of
581: #: `refs/heads/` with no `*`, is no pattern: it takes the one ref of that
582: #: name, which is no branch), and `skipped` for a negative refspec, which
...
690:     of `refs/heads/` that is no pattern and takes only the ref of that name,
691:     which is no branch and may stand beside the branches (the re-check of
692:     #1157, NIT 1), and a branch, a folder of them or a pattern of them,

That is true of an exact refs/h only. A remote can also hold a branch refs/heads/refs/h or a tag refs/tags/refs/h, and git completes the source refs/h to either. Measured on this branch's base, with a local bare remote per row (no network, GIT_CONFIG_GLOBAL=/dev/null, GIT_CONFIG_NOSYSTEM=1), the remote holding main and hy from one empty commit and then the ref of the row, and a fresh mount with that remote as origin running

git fetch origin '+refs/heads/*:refs/remotes/origin/*' '+refs/h:<destination>'

git 2.43.0 and git 2.47.1 gave the same answers:

the remote also has            destination                 result
branch refs/heads/refs/h       refs/remotes/origin/hy      128 Cannot fetch both refs/heads/hy and refs/heads/refs/h to refs/remotes/origin/hy
tag refs/tags/refs/h           refs/remotes/origin/hy      128 Cannot fetch both refs/heads/hy and refs/tags/refs/h to refs/remotes/origin/hy
exact ref refs/h (update-ref)  refs/remotes/origin/hy      128 Cannot fetch both refs/heads/hy and refs/h to refs/remotes/origin/hy
none of these                  refs/remotes/origin/hy      128 couldn't find remote ref refs/h
branch refs/heads/refs/h       refs/remotes/origin/not-a-branch    0
tag refs/tags/refs/h           refs/remotes/origin/not-a-branch    0
exact ref refs/h (update-ref)  refs/remotes/origin/not-a-branch    0

So the source can be a branch or a tag, and what clashes is the destination: the first three rows fail because origin/hy is where the glob puts the branch hy, and the same sources fetch with exit 0 onto a name no branch has. The fourth row is the other documented way a carried refspec fails, a source the remote lacks, and is not this clash.

The review (rv1235) measured two more completions on both gits: refs/refs/h and refs/remotes/refs/h are taken too (exit 0 onto a free name, and 128 Cannot fetch both refs/heads/hy and refs/refs/h and ... refs/remotes/refs/h ... onto origin/hy), so the list of what git completes the name to is open. It also measured a carried branch: +refs/heads/main:refs/remotes/origin/main and +refs/heads/rel/*:refs/remotes/origin/rel/* exit 0, where +refs/pull/7/head:refs/remotes/origin/main exits 128 Cannot fetch both refs/heads/main and refs/pull/7/head. So a carried source clashes onto a branch's name when it is not that branch.

What changed

Both passages say the same thing, in this file only. The comment above WHICH_CLAUSE, lines 580-586 (reflowed to the end of its sentence):

#: `carried` where none does (`carried-refs-h-not-a-pattern`, a start of
#: `refs/heads/` with no `*`, is no pattern: it takes the one ref that name
#: stands for, `refs/h` itself or a ref git completes it to, such as the
#: branch `refs/heads/refs/h` or the tag `refs/tags/refs/h`, and not the
#: branches as a set), and `skipped` for a negative refspec, which no
#: clause is asked of. `bump-leg.py`'s fetch of a leg is asked the same
#: rows (`test_bump_leg_fetch_refspecs.py`).

The docstring of test_which_clause_leaves_each_refspec_out, lines 692-697:

    of `refs/heads/` that is no pattern and takes only the one ref that name
    stands for (`refs/h` itself or a ref git completes it to, such as the
    branch `refs/heads/refs/h` or the tag `refs/tags/refs/h`), whose fetch
    clashes, as a pull request's ref does, where its destination is a
    branch's name (the re-check of #1157, NIT 1), and a branch, a folder of
    them or a pattern of them, each under the name `BRANCHES` gives it."""

• The diff against main is 11 lines added and 7 removed in tests/test_family_bump_fetch_refspecs.py, all in that comment and that docstring.
• The longest added line is 76 columns and the file's longest line is still 79. The file holds no non-ASCII line, and git diff --check is clean.
• The commit message of 0d76e4c59 and shape_materialize.py and bump-leg.py: the fetch for a branch's answer leaves out a pattern like refs/heads* that puts a branch under another name, its clauses move into _left_out, and the docstrings name the clashes left and the way back (#1100) #1157's body carry the old sentence and cannot be changed. These two passages are the only place to correct it.
• The code's own docstrings are left alone. scripts/bump-leg.py (1165) and scripts/shape_materialize.py (1874) define the clashing shape by examples and make no claim about refs/h. The docstring of gives_a_branch_another_name (scripts/shape_materialize.py:1721-1722) says "ANY OTHER SOURCE NAMES NO BRANCH", which is untrue where git completes the source to a branch. It is a shipped tool, so it is left for scripts/shape_materialize.py: the docstring of gives_a_branch_another_name says "ANY OTHER SOURCE NAMES NO BRANCH", but git completes a source such as refs/h to a branch, and its carried refspec's fetch exits 128 beside a branch hy (#1235 follow-up) #1238; this PR is wording only, in the test file.

Rows failing on main: none. No row is added or changed, so there is nothing for main to fail. Mutants: none, because no behaviour changed; carried-refs-h-not-a-pattern is the same row, and the syntax tree below shows nothing outside the docstring moved.

Round 1, after the review rv1235

• SHOULD 1. The docstring said refs/h clashes "like any carried source". A carried branch does not clash onto its own name, so "any" was untrue. It now says the fetch of the source clashes "as a pull request's ref does", where its destination is a branch's name.
• SHOULD 2 and NIT 3. Both passages listed "the branch or tag of that name", which reads as a complete list and could be taken for a branch h. Both now say refs/h itself or a ref git completes it to, "such as" the branch refs/heads/refs/h or the tag refs/tags/refs/h, with the refs spelled. The docstring says the fetch clashes (not the ref), and its citation, "(the re-check of shape_materialize.py and bump-leg.py: the fetch for a branch's answer leaves out a pattern like refs/heads* that puts a branch under another name, its clauses move into _left_out, and the docstrings name the clashes left and the way back (#1100) #1157, NIT 1)", follows that clause in parentheses.
• NIT 4. The sentence "make no claim about refs/h" is replaced by the paragraph above: the one code sentence that does cover it is left for scripts/shape_materialize.py: the docstring of gives_a_branch_another_name says "ANY OTHER SOURCE NAMES NO BRANCH", but git completes a source such as refs/h to a branch, and its carried refspec's fetch exits 128 beside a branch hy (#1235 follow-up) #1238.

Runs

All through the lane's runner run9.sh (stub gh first on PATH, GIT_SSH_COMMAND=false, GIT_CONFIG_GLOBAL=/dev/null), on the committed head 81582301e with the tree clean (dirty=0), Python 3.12.3. The git on that runner's PATH is /usr/bin/git, git 2.43.0 (measured with command -v git and git --version under the runner's PATH). The review's own runs had git 2.47.1 first on PATH and gave the same counts.

• Syntax tree (python3 -I, ast.dump): the file at this head and on main 0ed3e57f8, each with the docstring of test_which_clause_leaves_each_refspec_out removed, are equal (75050 characters of dump both). A control that renames WHICH_CLAUSE reports them different (75050 against 75052).
• -k carried-refs-h-not-a-pattern over tests/test_family_bump_fetch_refspecs.py and tests/test_bump_leg_fetch_refspecs.py: 2 passed, 123 deselected, as at 368b87e9b.
• tests/test_repo_hygiene.py and tests/test_path_guard_hygiene.py: 222 passed.
• git grep -n 'which is no branch' -- tests/test_family_bump_fetch_refspecs.py: finds nothing at this head (it finds lines 582 and 691 on main). The one other line of the file that has both refs/h and "no branch" is line 691, where "no branch" is said of refs/headsx/.

Merge-trees: git merge-tree --write-tree origin/main HEAD is clean (exit 0). Main was 0ed3e57f8 when read, and the merge base is e04826db4; main's one commit since touches none of the three files named here. Of the 49 open PRs, only this one touches tests/test_family_bump_fetch_refspecs.py (read from gh pr list --json files; the largest has 9 files).

Closes #1230

Lane: openreposhape-5 (openRepoShape-5)

🤖 Generated with Claude Code

Summary by Sourcery

Enhancements:

• Clarify test documentation to accurately describe how Git resolves the carried refs/h source ref and when its fetch conflicts with an existing destination.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

This wording-only PR updates one comment and one test docstring so they accurately describe Git’s ref completion and destination collision behavior for the carried refs/h refspec; no code, test rows, or behavior changes are made.

File-Level Changes

Change	Details	Files
Correct the fetch-refspec documentation to describe Git’s resolution of the refs/h source and the conditions under which its destination can clash with a branch name.	Explain that refs/h may resolve to the exact ref or to a ref Git completes it to, including example branch and tag namespaces. Clarify that the clash depends on the destination being a branch’s name rather than applying to every carried source. Replace the outdated “no branch” wording in the WHICH_CLAUSE comment and test docstring without changing test data or behavior.	tests/test_family_bump_fetch_refspecs.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#1230	Correct both passages in tests/test_family_bump_fetch_refspecs.py so they describe Git resolving the source refs/h to the exact ref or a ref it completes to, including a branch or tag, rather than claiming it is never a branch.	✅

Possibly linked issues

• tests/test_family_bump_fetch_refspecs.py: a comment and a docstring say a refs/h source takes no branch, but git completes it to a branch or tag of that name, and beside a branch hy the fetch exits 128 Cannot fetch both (#1157 follow-up) #1230: The PR updates both passages identified by the issue to accurately describe refs/h resolution and its possible fetch clashes.

---

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]

Independent review of #1235 (#1230) for lane openRepoShape-5, by rv1235 (sonnet), at 644982d: READY

I found no MUST. Two SHOULDs show that the new wording is still not true of git in two places. I recommend folding both in before the PR leaves draft. Each is a one-sentence rewording, and the syntax-tree check can then be re-run.

What I checked and measured

Setup: disk had 13G free at the start and 30G at the end. My worktree is /workspace/projects/openRepoShape-worktrees/rv1235-review, detached at 644982da1d542854f9dc22b5fbce9a229fb90367, and it is clean. My folder is $R = /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v130/rv1235, with notes in $R/STATE.md. I pushed nothing and made no GitHub writes. The only gh calls were reads: issue view, pr view, one pr list and one gh api GET of main.

1. Probes of git behaviour. Local bare remotes, GIT_CONFIG_GLOBAL=/dev/null, GIT_CONFIG_NOSYSTEM=1, GIT_SSH_COMMAND=false. The fetch was +refs/heads/*:refs/remotes/origin/* plus +refs/h:<dest>. Each remote had main and hy, and each source ref was a different commit, so I could see which one git took. Logs are $R/probe-g243b.log and $R/probe-g247b.log. They are identical for git 2.43.0 (/usr/bin/git) and git 2.47.1 ($Q/v115/w764/git247/bin/git).

Remote also has	Destination origin/hy	Destination origin/not-a-branch
branch refs/heads/refs/h	128, Cannot fetch both refs/heads/hy and refs/heads/refs/h to refs/remotes/origin/hy	0, holds the branch's commit
tag refs/tags/refs/h	128, ... refs/tags/refs/h ...	0, holds the tag's commit
exact refs/h (update-ref)	128, ... refs/h ...	0, holds that commit
none of these	128, couldn't find remote ref refs/h	128, same

The four cases in the PR body's table hold on both gits. "The one ref" also holds. When several exist, git takes one:

• the exact ref beats a tag or a branch;
• a tag beats a branch;
• a branch alone is taken.

Two other probes, $R/probe2-g243.log and $R/probe2-g247.log, support the findings below.

2. The issue's Verify items.

• Syntax tree (python3 -I, 3.12.3, $R/astcmp.py): with the docstring of test_which_clause_leaves_each_refspec_out removed from both sides, main and head give 75050 characters of dump each, and they are EQUAL. Three checks back this up:
  • Controls: renaming WHICH_CLAUSE gives 75050 against 75052 and DIFFERENT. With the docstrings left in, the trees are DIFFERENT.
  • Location: the hunks are @@ -581,4 +581,5 (only #: lines) and @@ -690,4 +691,6 (inside the docstring, which spans lines 665-696 at head).
  • Check: git diff --check is clean.
• -k carried-refs-h-not-a-pattern over both files: 2 passed, 123 deselected ($R/runA.log).
• Other ids: --collect-only gives 68 + 57 = 125 ids ($R/runD.log). -k test_which_clause_leaves_each_refspec_out gives 72 passed, 53 deselected ($R/runC.log).
• Hygiene: tests/test_repo_hygiene.py plus tests/test_path_guard_hygiene.py give 222 passed ($R/runB.log).
• Grep: git grep -n 'which is no branch' -- tests/test_family_bump_fetch_refspecs.py finds nothing at head (rc 1). On main it finds lines 582 and 691.
• Columns and characters: 11 added lines, longest 74 columns, none over 79, no trailing whitespace or tabs, 0 non-ASCII characters. The file's longest line is still 79 and it has 0 non-ASCII lines.

All runs went through run9.sh with EMAIL=service@opensoft.dev, as background calls. Their PATH had git 2.47.1 first, so these runs used 2.47.1 where the PR body says 2.43.0. I ran no mutants, because the trees show no behaviour moved.

3. The PR body's claims.

• Counts, line numbers and blob 6e752bbca9c9 hold.
• The diff is 11 insertions and 8 deletions in one file.
• git merge-tree --write-tree origin/main HEAD exits 0, and its tree dcb03d80 equals HEAD's tree.
• Main is still e04826db4 (gh api GET) and is the merge base.
• $R/open-prs.json lists 49 open PRs including test_family_bump_fetch_refspecs.py: the comment on WHICH_CLAUSE and the docstring of test_which_clause_leaves_each_refspec_out say the source refs/h takes the one ref git completes it to, which may be a branch or tag, not no branch (#1230) #1235, so 48 others. None of the 48 touches the file, and the largest has 9 files (family.py: the add, bump and remove lines its remedies name begin with the interpreter and the script's path, quote the row's name, fill in the family's org, say the branch they run on, and member-already-present prints its remove (#1127) #1201).
• closingIssuesReferences is [1230], and the Closes #1230 line is the only closing keyword. body-guard.py exits 0.
• The commit has the right identity and one Closes line. Its subject is 247 characters.

4. Other sentences saying the source refs/h takes no branch.

• Within the test file, no sentence says that of the source refs/h. The remaining "no branch" lines are about refs/hidden/..., commits and outside-origin-prefix.
• No other file has a sentence about the source refs/h. The one exception is the code sentence in NIT 4, which covers it without naming it.

Findings

SHOULD 1: "like any carried source" is false of a carried branch. The docstring (lines 693-694) says refs/h is "a ref that, like any carried source, clashes where its destination is a branch's name".

• $R/probe2-g243.log and $R/probe2-g247.log, case (a):
  • +refs/heads/main:refs/remotes/origin/main fetches with rc 0.
  • +refs/heads/rel/*:refs/remotes/origin/rel/* fetches with rc 0.
  • +refs/pull/7/head:refs/remotes/origin/main fails with rc 128, Cannot fetch both refs/heads/main and refs/pull/7/head.
• The file's own carried-one-branch and carried-branches-in-their-own-folder rows have a branch's name as destination and do not clash. The same sentence's last clause, "a branch ... each under the name BRANCHES gives it", contradicts "any".
• The code's own docstrings limit the clash to a source that names no branch. This PR introduced the over-generalization, copied from the issue's suggested wording.
• Fix: "like a pull request's ref, clashes where..." or "like any carried source that is not the branch itself".

SHOULD 2: the list "refs/h itself or the branch or tag of that name" is closed, but git completes the name to more. This is in both passages, at comment lines 581-582 and docstring lines 691-692.

• Measured on both gits, onto a free name: refs/refs/h, refs/remotes/refs/h and refs/remotes/refs/h/HEAD each fetch with rc 0 and are taken. The first two onto origin/hy fail with rc 128, Cannot fetch both refs/heads/hy and refs/refs/h and ... refs/remotes/refs/h ....
• A plain git push to a bare remote made refs/refs/h and refs/remotes/refs/h. Only the exact refs/h is refused as a funny ref. I made refs/remotes/refs/h/HEAD only by update-ref.
• So the sentence has the same defect as the original NIT 1: an incomplete enumeration read as complete. The goal, that no reader is told the source is never a branch, is met.
• The issue's own line "what such a remote can hold under that name is a branch or a tag" is incomplete in the same way.
• Fix, which also covers NIT 3: "refs/h itself or a ref git completes it to, such as the branch refs/heads/refs/h or the tag refs/tags/refs/h".

NIT 3: wording.

• Neither passage spells refs/heads/refs/h or refs/tags/refs/h. "The branch or tag of that name" can be misread as a branch h.
• In the docstring parenthetical, a ref does not clash, the fetch does. The colon before the citation ("...name: the re-check of shape_materialize.py and bump-leg.py: the fetch for a branch's answer leaves out a pattern like refs/heads* that puts a branch under another name, its clauses move into _left_out, and the docstrings name the clashes left and the way back (#1100) #1157, NIT 1") reads as a reason, not a source. "(the re-check of shape_materialize.py and bump-leg.py: the fetch for a branch's answer leaves out a pattern like refs/heads* that puts a branch under another name, its clauses move into _left_out, and the docstrings name the clashes left and the way back (#1100) #1157, NIT 1)" after the clause would be clearer.
• Otherwise the English is clear. The reflowed comment keeps its unchanged text word for word.

NIT 4: the PR body says shape_materialize.py and bump-leg.py "make no claim about refs/h". That is not quite right.

• scripts/shape_materialize.py:1721-1722, in the docstring of the clause _left_out uses, says "ANY OTHER SOURCE NAMES NO BRANCH". That covers the source refs/h, since it is not under refs/heads/, and is untrue where git completes it to a branch.
• shape_materialize.py:1874 and bump-leg.py:1165 ("whose source names no branch") define the clashing shape the same way. They never name refs/h and sit well as examples.
• All three are out of scope here: the PR is wording-only in the test file, and shape_materialize.py is a pinned copy.
• Suggestion: say "left for a follow-up" in the body instead of "make no claim", or file the follow-up.

NIT 5: the live PR body ends with a Sourcery section. ## Summary by Sourcery, about lines 91-93, comes after the Lane: line, so the last line is no longer the Lane line. body-guard.py still exits 0. The coordinator may want to strip it before any squash message is built.

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

[brettheap]

Re-check of #1235 (#1230) for lane openRepoShape-5, by rv1235 (sonnet), at 8158230: READY

I found no MUST and no SHOULD. SHOULD 1, SHOULD 2, NIT 3 and NIT 4 of my first review are fixed, and I found three small NITs.

$R below = /tmp/claude-1000/-workspace-projects-openRepoShape/50cede29-ab82-4ca3-9f67-d98e1a58c8d2/scratchpad/v130/rv1235.

What I checked and measured

My worktree /workspace/projects/openRepoShape-worktrees/rv1235-review is now detached at 81582301ebab28792bc65a649e9b26c054cc1a17, clean. The object was already local, so I did no fetch. I made no GitHub writes.

(1) The new sentences, against my earlier probes.

• Comment, lines 581-584. The text is "the one ref that name stands for, refs/h itself or a ref git completes it to, such as the branch refs/heads/refs/h or the tag refs/tags/refs/h". It is an open list now. My probes in $R/probe-g243b.log and $R/probe-g247b.log show it holds on git 2.43.0 and 2.47.1:
  • the exact ref, the branch and the tag are each taken;
  • so are refs/refs/h and refs/remotes/refs/h;
  • the exact ref beats the tag, which beats the branch, so "the one ref" holds.
• Docstring, lines 692-697. "Whose fetch clashes, as a pull request's ref does, where its destination is a branch's name." The pull-request half is measured in $R/probe2-g243.log and $R/probe2-g247.log: +refs/pull/7/head:refs/remotes/origin/main exits 128 Cannot fetch both refs/heads/main and refs/pull/7/head .... The refs/h half is measured too: 128 onto origin/hy for the exact ref, branch and tag.
• Citation. It now follows the clause in parentheses, and the fetch is what clashes, not the ref.
• Commit message. Its probe claims are true: the carried branch exits 0, the pull request exits 128, and refs/refs/h and refs/remotes/refs/h are completions. Its subject is 241 characters.
• One new probe, for an edge ($R/probe3-g243.log, $R/probe3-g247.log; git 2.43.0 and 2.47.1 give the same result). A remote with the branch refs/heads/refs/h and the destination refs/remotes/origin/refs/h, which is the glob's own name for that branch, fetches with rc 0. Onto origin/hy it exits 128. See NIT 1.

(2) The gates at the new head. All through run9.sh, as run_in_background calls, with EMAIL=service@opensoft.dev, tree clean (dirty=0). The runner's PATH gives /usr/bin/git, git 2.43.0 ($R/r2-runner-git.log).

• Syntax tree (python3 -I, 3.12.3, $R/astcmp.py): the file at head against main 0ed3e57f8, with the docstring of test_which_clause_leaves_each_refspec_out removed from both, gives 75050 and 75050 characters, EQUAL. The control that renames WHICH_CLAUSE gives 75052 and DIFFERENT. The docstring spans are 664-693 on main and 666-697 at head.
• -k carried-refs-h-not-a-pattern over both files: 2 passed, 123 deselected ($R/r2-runA.log).
• Hygiene: tests/test_repo_hygiene.py plus tests/test_path_guard_hygiene.py give 222 passed ($R/r2-runB.log).
• Grep: git grep -n 'which is no branch' -- tests/test_family_bump_fetch_refspecs.py finds nothing (rc 1). Nothing remains of "branch or tag of that" or "like any carried source" in tests/ or scripts/. The only line with both refs/h and "no branch" is 691, where it is said of refs/headsx/.
• Size and characters: against the base e04826db4, 11 lines are added and 7 removed. The longest added line is 76 columns, none are over 79, and there is no trailing whitespace. git diff --check is clean. The file has 0 non-ASCII lines and its longest line is 79.
• Merge-tree: git merge-tree --write-tree origin/main HEAD exits 0, with origin/main at 0ed3e57f8.

(3) The live body and #1238.

• Body, confirmed:
  • Two commits, 644982da1 and 81582301e.
  • The comment is at lines 580-586 and the docstring at 692-697.
  • The diff is 11 added and 7 removed, longest added line 76.
  • Main is still 0ed3e57f8 (gh api GET). The file's blob there is 6e752bbca9c9 (contents API).
  • Main's one commit since the base touches only adopt-project.py and tests/test_adopt_next_make_reads_first.py (gh api compare). None of the three files named in the body.
  • closingIssuesReferences is [1230], and Closes #1230 is the only closing line. body-guard.py exits 0.
  • Only test_family_bump_fetch_refspecs.py: the comment on WHICH_CLAUSE and the docstring of test_which_clause_leaves_each_refspec_out say the source refs/h takes the one ref git completes it to, which may be a branch or tag, not no branch (#1230) #1235 touches the file (one gh pr list, $R/open-prs2.json).
• scripts/shape_materialize.py: the docstring of gives_a_branch_another_name says "ANY OTHER SOURCE NAMES NO BRANCH", but git completes a source such as refs/h to a branch, and its carried refspec's fetch exits 128 beside a branch hy (#1235 follow-up) #1238's line and function claims, confirmed:
  • gives_a_branch_another_name is at scripts/shape_materialize.py:1671, and the sentence is at 1720-1723.
  • git grep -i 'other source names no' finds only shape_materialize.py:1721, on head and on origin/main.
  • Lines 1874 and bump-leg.py:1165 are as quoted.
  • I called the function: gives_a_branch_another_name("refs/h", ...) returns False, so the refspec is carried. It also returns False for refs/pull/7/head.
• scripts/shape_materialize.py: the docstring of gives_a_branch_another_name says "ANY OTHER SOURCE NAMES NO BRANCH", but git completes a source such as refs/h to a branch, and its carried refspec's fetch exits 128 beside a branch hy (#1235 follow-up) #1238's measured table: it matches my probe logs, including the exact over tag over branch order and the push results.

Findings

NIT 1: one literal edge remains in the docstring. "Whose fetch clashes ... where its destination is a branch's name" is not true of refs/h when the destination is the name of the very branch it completes to. This is the same shape as my earlier SHOULD 1, but the remote needs the branch refs/heads/refs/h and the destination must be origin/refs/h. It is exact for a pull request's ref. Optional fix: "where its destination is another ref's branch name".

NIT 2: #1238's text has two small gaps.

• Its problem statement lists five completions and leaves out refs/remotes/refs/h/HEAD. That one is taken too (rc 0 onto a free name, probe 1, remoteshead-nb, both gits).
• Its suggested docstring text, "(refs/h: itself, or the branch ..., or the tag ...)", is a closed-looking list like the one SHOULD 2 fixed.
• Saying "such as" there avoids a third round. The issue says the wording is the owner's.

NIT 3: the live body.

• The bot's ## Summary by Sourcery section is back after the Lane: line (about lines 96-103), though the body's "Round 1" says it is not part of the body. body-guard.py still exits 0. Strip it before any squash message is built.
• "Of the 49 open PRs" is 51 now, 50 besides test_family_bump_fetch_refspecs.py: the comment on WHICH_CLAUSE and the docstring of test_which_clause_leaves_each_refspec_out say the source refs/h takes the one ref git completes it to, which may be a branch or tag, not no branch (#1230) #1235. The claim that only test_family_bump_fetch_refspecs.py: the comment on WHICH_CLAUSE and the docstring of test_which_clause_leaves_each_refspec_out say the source refs/h takes the one ref git completes it to, which may be a branch or tag, not no branch (#1230) #1235 touches the file still holds.

Lane: openreposhape-5 (openRepoShape-5)

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

Sourcery assessment

Approved.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook