Context
A cleanup sweep across 21 repositories on a df12 development host ran
git plonk --dry-run in every main repository that has a *.worktrees
sibling. It reported "No matching git donkey worktrees found" in all 21,
while a manual sweep immediately afterwards found and removed 43
worktrees that were clean and either had a merged pull request or had been
idle for more than seven days. git plonk is therefore not being overly
cautious within its rules — its recognition rules never fire against the
branch names in real use.
Shortcoming 1: the roadmap pattern requires a trailing suffix
plonk_policy._ROADMAP_BRANCH_PATTERN is:
re.compile(r"^(?:(\w+)-)?(\d+)-(\d+)-(\d+)(\w+)?-(?:(\d+)-)?")
The pattern only matches when the dotted id is followed by another -
segment, so it recognizes 2-2-1-description but not a bare task id.
leynos/df12-build names its task branches with no descriptive
suffix, per its own recognizer
(src/workflows/df12-build-odw/recovery-decision.ts):
export const TASK_BRANCH_RE = /^roadmap-((?:\d+-)*\d+)(-addendum)?$/
Real examples that plonk missed despite merged PRs whose squash titles
carried the (2.2.1)-style marker: roadmap-2-2-1 and roadmap-6-4-1
in leynos/stilyagi (PRs #54 and #55, both merged).
Suggested fixes:
- make the trailing separator optional, and accept variable-depth dotted
ids (df12 roadmap ids run from N.N to N.N.N.N), rather than exactly
three numeric segments; and
- recognize the df12-build shapes explicitly:
roadmap-<id-with-dashes>
and roadmap-<id-with-dashes>-addendum (the addendum form completes
when the parent task and every addendum sub-task are ticked, so its
marker is the same dotted id).
Shortcoming 2: issue branches key on the issue number, but squash merges carry the PR number
For issue-62-polymer-corrections, plonk derives the marker (#62) and
scans trunk history for it. The branch merged via squash as PR #63,
so the trunk commit title ends in (#63) and the worktree is never
recognized as complete. Additional commit-message patterns worth
accepting when checking history for an issue-N branch:
Closes #N, Fixes #N, Resolves #N (and their -d/-s variants),
which GitHub propagates into many squash bodies;- classic merge commits:
Merge pull request #M from <owner>/<branch>,
where the branch segment itself matches, making the PR number
irrelevant; and
- the branch name appearing verbatim in a squash title or body.
Suggestion: GitHub API fallback for unmatched branch names
Forty of the forty-three worktrees removed in the manual sweep had
purely descriptive branch names (fix-markdown-gates,
adopt-whitaker, typos-shared-base, …) that no offline pattern can
map to a completion marker. When a branch name matches no expected
pattern (or a pattern matches but no marker is found), a fallback query
answers the question authoritatively:
gh pr list --head <branch> --state merged --json number -L 1
(or the equivalent GraphQL pullRequests(headRefName:) lookup). A
MERGED result is a stronger signal than any commit-message heuristic
and also covers squash and rebase merges uniformly. A cheaper offline
approximation, when network access is undesirable, is git fetch --prune followed by checking whether the branch's upstream is gone —
weaker, since it cannot distinguish merged from abandoned, but a useful
--offline tier.
Suggested precedence: marker patterns first (fast, offline), API
fallback second, upstream-gone as an opt-in heuristic; --dry-run
output could label which signal justified each candidate.
Context
A cleanup sweep across 21 repositories on a df12 development host ran
git plonk --dry-runin every main repository that has a*.worktreessibling. It reported "No matching git donkey worktrees found" in all 21,
while a manual sweep immediately afterwards found and removed 43
worktrees that were clean and either had a merged pull request or had been
idle for more than seven days.
git plonkis therefore not being overlycautious within its rules — its recognition rules never fire against the
branch names in real use.
Shortcoming 1: the roadmap pattern requires a trailing suffix
plonk_policy._ROADMAP_BRANCH_PATTERNis:The pattern only matches when the dotted id is followed by another
-segment, so it recognizes
2-2-1-descriptionbut not a bare task id.leynos/df12-buildnames its task branches with no descriptivesuffix, per its own recognizer
(
src/workflows/df12-build-odw/recovery-decision.ts):Real examples that plonk missed despite merged PRs whose squash titles
carried the
(2.2.1)-style marker:roadmap-2-2-1androadmap-6-4-1in
leynos/stilyagi(PRs #54 and #55, both merged).Suggested fixes:
ids (df12 roadmap ids run from
N.NtoN.N.N.N), rather than exactlythree numeric segments; and
roadmap-<id-with-dashes>and
roadmap-<id-with-dashes>-addendum(the addendum form completeswhen the parent task and every addendum sub-task are ticked, so its
marker is the same dotted id).
Shortcoming 2: issue branches key on the issue number, but squash merges carry the PR number
For
issue-62-polymer-corrections, plonk derives the marker(#62)andscans trunk history for it. The branch merged via squash as PR #63,
so the trunk commit title ends in
(#63)and the worktree is neverrecognized as complete. Additional commit-message patterns worth
accepting when checking history for an
issue-Nbranch:Closes #N,Fixes #N,Resolves #N(and their-d/-svariants),which GitHub propagates into many squash bodies;
Merge pull request #M from <owner>/<branch>,where the branch segment itself matches, making the PR number
irrelevant; and
Suggestion: GitHub API fallback for unmatched branch names
Forty of the forty-three worktrees removed in the manual sweep had
purely descriptive branch names (
fix-markdown-gates,adopt-whitaker,typos-shared-base, …) that no offline pattern canmap to a completion marker. When a branch name matches no expected
pattern (or a pattern matches but no marker is found), a fallback query
answers the question authoritatively:
(or the equivalent GraphQL
pullRequests(headRefName:)lookup). AMERGEDresult is a stronger signal than any commit-message heuristicand also covers squash and rebase merges uniformly. A cheaper offline
approximation, when network access is undesirable, is
git fetch --prunefollowed by checking whether the branch's upstream is gone —weaker, since it cannot distinguish merged from abandoned, but a useful
--offlinetier.Suggested precedence: marker patterns first (fast, offline), API
fallback second, upstream-gone as an opt-in heuristic;
--dry-runoutput could label which signal justified each candidate.