You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
park's not-carried report counts a leg's unpushed commits against the root's tracking_branch, not the leg's own branch:, so work on a declared branch is never reported #242
park's not-carried report counts the commits a leg has on its tracking branch that origin has never seen, against the ROOT's tracking_branch, for every leg. The root's bootstrap.py places a leg on str(leg.get("branch") or branch), so a leg whose row in project.yaml declares its own branch: has its unpushed work on THAT branch, and park asks about the wrong one.
parkreport_repos (park:526-548 at main f5c3bcd) emits each leg's row as leg<TAB><root's branch><TAB><path>, with the comment "A LEG'S branch is the ROOT's tracking_branch: — that is the one value scripts/bootstrap.py places every leg on" (park:536-537). That comment is not true for a leg that declares a branch:.
not_parked_report (park:579) hands that branch to unpushed_on_tracking (park:559), which needs both refs/heads/<branch> and refs/remotes/origin/<branch> and counts origin/<branch>..<branch>.
So for a leg with branch: develop, three local commits on develop that origin has not seen are never counted: park asks about main, finds nothing ahead, and the report ends without naming the leg. That report is what tells a person which work park did NOT carry, so it is data-loss-adjacent: the miss is silent.
resume and status had the same assumption and are addressed by #238 (for #235): resume's root_legs_ok and status's estate_repos now take each leg's branch from leg_branch_of, the shared helper that reads the leg row's own branch:, else the root's tracking_branch. park was left out because #235's finding does not name it.
Found by the independent review of #238 (review 5561239715).
Suggested fix
In report_repos, give each leg's row leg_branch_of "<root>" "<leg>", falling back to the root's branch on an empty answer, as status's estate_repos does in #238:
while IFS= read -r leg;do
legbranch="$(leg_branch_of "$ESTATE_ROOT""$leg")"printf'leg\t%s\t%s\n'"${legbranch:-$branch}""$ESTATE_ROOT/$leg"done<<(submodule_paths "$ESTATE_ROOT")
(and the same in the family loop, with $ESTATE_DIR/$member as the root). leg_branch_of is already in park's copy of the shared resolver block, unused. Then replace the comment at park:536-537.
Add a test beside the not-carried report's: a root whose spec leg declares branch: develop, with local commits on develop that origin lacks; it must be reported, and it must fail without the change. The unpushed line prints the branch, so it can name develop.
CLAIMED — lane openRepoTools-1, session df82f553-7803-49c4-8ddf-3f9acdcb8ee0@Eagle, 2026-10-18T14:09:37Z, for #242
Logged in lanes/log/openRepoTools-1.md at 8d1fef5b878fb67c00a24e198a273d802fd129f0.
The three reads (lane-collision-protocol Rule 1):
1. existing `CLAIMED —` comments on opensoft/openRepoTools#242:
none
2. `gh pr list --repo opensoft/openRepoTools --state all --search "#242"`, kept where the row or its body names `#242`:
238 resume and status hold each leg to the branch bootstrap puts it on: the leg row's own branch:, else the root's tracking_branch (#235) fix/resume-leg-own-branch-235 MERGED
3. `git ls-remote --heads git@github.com:opensoft/openRepoTools` branches naming `242` as a whole token:
none
RELEASED — lane openRepoTools-1, session df82f553-7803-49c4-8ddf-3f9acdcb8ee0@Eagle, 2026-10-18T17:23:31Z, for #242 — PR #249 landed as fe58808 (Fixes #242) and #242 is closed; tree ort-park-leg-branch-242 removed
Activity
Apply the independent review of #238: test leg_branch_of's parsing, f…
resume and status hold each leg to the branch bootstrap puts it on: t…
brettheap commentedon Oct 18, 2026
CLAIMED — lane openRepoTools-1, session df82f553-7803-49c4-8ddf-3f9acdcb8ee0@Eagle, 2026-10-18T14:09:37Z, for #242
Logged in
lanes/log/openRepoTools-1.mdat8d1fef5b878fb67c00a24e198a273d802fd129f0.The three reads (lane-collision-protocol Rule 1):
Apply the independent review of #249: survive an unreadable member ma…
brettheap commentedon Oct 18, 2026
RELEASED — lane openRepoTools-1, session df82f553-7803-49c4-8ddf-3f9acdcb8ee0@Eagle, 2026-10-18T17:23:31Z, for #242 — PR #249 landed as fe58808 (Fixes #242) and #242 is closed; tree ort-park-leg-branch-242 removed
family.yaml values are read the way openRepoShape v1.1.0 reads them, …