Beagle SCM

SUBS-038: a sub re-get whose .gitmodules url BASENAME changed since the first mount fetches the wrong shard → object-not-found

When a submodule's declared .gitmodules url BASENAME differs between the original mount and a later re-get (GET or whole-tree PATCH), the re-get fetches into a shard named by the NEW url basename while the existing mount + checkout live under the OLD basename. subs_pin_present / KEEPHas then reports the pin present in the wrong shard, SubMount short-circuits, and the spawned sniff get <pin> opens the mount's shard and fails object not found / SNIFFFAIL / BEDOGEXIT. Found while building the PATCH-005 hermetic fixture; not the real dogs/journal flow (url basenames are stable there), so low priority — but a real latent gap.

Input

Context

• Repro: clone a beagle parent whose sub ch is declared with url

  basename ch; later rewrite the committed .gitmodules url to a different basename (dead-libch) and be get / be patch an advanced pin. The fetch targets the dead-libch shard but the mount is ch → the child checkout reads ch, misses the pin.

• Sibling-shard swap (subs_sibling_shard_has_pin, sniff/SUBS.c) keys

  on the PATH basename, but the SHARD dir + anchor are named by the URL basename — they diverge when the url basename changes.

• Workaround in tests: keep the dead url basename STABLE from the first

  clone (so the shard name never changes). PATCH-005/008 guard tests (test/patch/38, 41) do this.

Goals

• A sub re-get keys the shard/anchor consistently across mounts — prefer

  the PATH basename (stable) over the URL basename, or detect+migrate an existing OLD-basename mount when the url basename changes.

Outcome

• OPEN — filed 2026-06-27 (PATCH-005 fixture session). Latent edge

  case (url-basename change mid-stream); not blocking the PATCH chain.

• Audit 2026-07-07: no commits reference SUBS-038; unchanged. NOTE: not

  listed on the top board (todo/README.mkd) — a board gap (LOW, latent).