Beagle SCM

GET-032: be get of an offline submodule mount reports ok but writes no files

When be get mounts a submodule whose official remote is UNREACHABLE but whose pinned objects are ALREADY in the local/shared store, it records the manifest/ref and reports <n> ok, yet materializes ZERO files (empty mount dir). A failed fetch with locally-resolvable objects must still run the checkout — 237 ok and an empty worktree must never coexist. Hit twice this session (JS-042/JS-043 worktree setup). Method: Issues.

Input

Context

• abc's .gitmodules URL is https://github.com/gritzko/libabc.git; with the network down, be get of the parent mounts abc, the abc fetch fails (ssh/https refused), but the pinned commit (6e3b93f8) objects ARE in the local store.
• Symptom: be status in the mount shows ?6e3b93f86ca5… 237 ok (objects present) while the abc/ dir is EMPTY (no files on disk). Workaround used by both workers: copy abc/ from a sibling worktree.
• Independent of (and a sibling to) the already-filed be get path-form file: URL misparse; both surfaced in the same worktree-setup step.

Goals

• On a submodule fetch failure where the pinned objects resolve locally, be get materializes the files from the local store (or refuses with a clear error) — never a silent empty mount that still reports ok.
• The ok count and a populated worktree stay consistent.

Constraints

• sniff GET submodule-mount path; offline-tolerant — don't require the remote when objects are local. Likely the fetch-fail short-circuits the checkout step.

WIP

Design decisions

• (pending) — separate the submodule FETCH from the CHECKOUT: a failed fetch with locally-resolvable objects should still run the materialize pass.

TODOs

• Repro: unreachable submodule remote + pinned objects present locally → be get parent → assert the mount has FILES, not just an ok count.
• Fix the submodule get to materialize from the local store on fetch-fail-but-objects-present; keep ok consistent with on-disk files.
• Audit 2026-07-07: no GET-032 commit landed; BEActSubsGet (beagle/BE.cli.c:2065) now DOCUMENTS "skipped when its pin is already present in the local shard (offline-safe)" — verify that skip path actually RUNS the checkout (the bug was exactly fetch-fail short-circuiting materialise), and note the JS twin already reuses an already-local pin (shared/submount.js "Already-local pin?" arm) as the model.

Blockers and bummers

• None. Surfaced by the JS-042/JS-043 worktree setup (offline abc).

Outcome

• (pending)