?/<sub>/.<parent> won't resolve — sub can't be re-attached by name (GRAFNONE)STALE 2026-07-15 (gritzko): the synthetic dot-branch is REMOVED (URI-016 decision 5, SUBS-054), so the query this ticket cannot resolve stops existing. Re-attaching a sub by name is now addressing its pin explicitly — ///path/to/sub#pin (URI-016 decision 7). Already called wontfix by SUBS-050. Original filing kept below as evidence.
A detached submodule should re-attach to its synthetic dot-branch by name —
be get '?/<sub>/.<parent>' — the canonical coordinate its commits live on. But
that query won't RESOLVE: be head '?/abc/.dogs' (the get dry-run) returns
graf: head: cannot resolve target / GRAFNONE at both the parent and the recursed
sub level, even though the abc shard's refs DO carry ?/abc/.dogs#<sha>. So a
detached sub cannot be re-attached to its dot-branch by name. Flagged as a
SUBS-021 follow-up; confirmed 2026-06-16. Research → fix. Method: Issues.
~/beagle, read-only dry-run): be head '?/abc/.dogs' →
graf: head: cannot resolve target / Error: GRAFNONE (twice — it recurses
be: head . / be: head abc and both miss). Same with a #<sha> fragment.~/beagle/.be/abc/refs: 26616Bkc1V post ?/abc/.dogs#02a23dc3… — the branch
EXISTS, the resolver just can't map the ?/<sub>/.<parent> query to it.?<sha> and its commits sit on the synthetic
coordinate ?/<sub>/.<parent> (see submodule-synthetic-branch-post,
submodule-tip-detached-form). The POST composer writes that branch correctly;
GET/HEAD resolution of it is the gap.be get '?/<sub>/.<parent>' (and be head) RESOLVES the synthetic dot-branch to
its tip and re-attaches the sub there — symmetric with how POST writes it.#<sha> fragment pins the cur.sniff/GET.c synth/DOGQueryStripProject path ~:1910-1999; graf head's
GRAFResolveTip/REFSResolve); do NOT re-roll branch parsing. No new flags.?/<sub>/.<parent> resolution returns GRAFNONE — is the
query's leading /<sub> segment stripped wrong, is the .-prefixed parent
coordinate not matched against the dot-branch refs row, or is the recursion target
mis-derived? Likely the DOGQueryStripProject / synthetic-branch resolve path.be get '?/<sub>/.<parent>'
→ assert the sub re-attaches to the dot-branch tip (RED = GRAFNONE today).#<sha> pins cur.?/<sub>/.<parent>
branch: test/get/11-sub-clone-recursive (+ get/31, get/37) resolve the sub at the
.gitmodules pin and pass on trunk; NO test/get/ case ever resolves a
?/<sub>/.<parent> query (that form is POST-side only — post/43/44). So the
SNIFFFAIL is reachable only by hand-typing be get '?/<sub>/.<parent>', an internal
coordinate nobody uses — no real-world breakage. The be head probe that surfaced it
is remote-oriented and was a poor proxy. A fix exists (below) but is not worth landing;
~/todo/SUBS-023 discarded. Dropped from the active index./sub/.par, but both
resolvers ran DOGQueryStripProject first, peeling off <sub> → bare .par →
KEEPResolveRef/REFSResolve miss → GRAFNONE (graf/LOG.c:771) / SNIFFFAIL
(sniff/GET.c:1918). Fix: new fun b8 DOGQueryIsSynthBranch(query) (dog/DOG.h,
recognizes ?/<sub>/.<parent>) → graf/LOG.c + sniff/GET.c SKIP the strip and resolve
the FULL path via the existing REFS machinery; a 40-hex #<sha> fragment pins the cur
(scoped to synth branches, so ?<branch>#<sha> keeps tip-checkout). New
test/get/52-sub-synth-reattach; 307/307. Awaiting gate. (Rewinding to an OLDER
pin still needs --force per the normal non-ff guard — out of scope.)~/beagle then restored them;
verified the live tree is clean (those files ok, no leftovers) — no WIP lost.