Beagle SCM

GET-022: no per-file checkout-from-rev — be get <path>?<rev> drops the path, treats the rev as a branch

There is no way to materialize ONE file at a given rev into the worktree (git checkout <rev> -- <path> parity). be get <path>?<rev> silently DROPS the path and resolves ?<rev> as a branch/ahead-behind target → a no-op or KEEPNONE. The blob:/cat: projection resolves the file at the rev for READING, but no VERB writes it back. This is the tool GET-021 needs: fix a single stale working file without a whole-tree be get that would clobber unrelated WIP. Method: Issues.

Input

Context

• Repro (~/beagle, fixing the GET-021 stale graf/BLAME.c):

  be get! graf/BLAME.c?f6bea1c5 → sniff: get: cannot resolve graf/BLAME.c?f6bea1c5 / KEEPNONE (sniff/GET.c:1711/1821).

• Probed with the be head dry-run: be head 'graf/BLAME.c?f6bea1c5' →

  head:?f6bea1c5 / ?f6bea1c5/: 0 ahead, 0 behind, 0 changed — the PATH is dropped and f6bea1c5 is parsed as a branch name. be head 'graf/BLAME.c?#f6bea1c5' → whole-branch ahead/behind, path again ignored. The blob:/cat: projection (be blob:graf/BLAME.c?f6bea1c5) DOES resolve the file content at the rev.

• So path-scope on get only means "which sub(s) to recurse into" (BE.cli.c:1887,

  "ONLY a LOCAL bareword path is a within-wt scope"; SUBS-018) — NOT "check out this file at this rev". There is no per-file restore.

• Why it matters: GET-021's stale-file fix wants exactly this — restore one lagging

  file to cur — without be get '?#<tip>' over the whole tree, which a --force would use to also overwrite unrelated dirty WIP (e.g. ABC.md).

Goals

• be get [!] <path>?<rev> (or the agreed canonical form) writes <path>'s blob at

  <rev> into the worktree and records it; --force (!) overwrites a dirty path; no whole-tree checkout, no touch of other paths' WIP. Multiple paths allowed.

• A clear error when <path> does not exist at <rev> (not a silent path-drop /

  branch-ahead-behind no-op).

Constraints

• Reuse the existing blob resolution the blob:/cat: projector already uses (it

  resolves <path>?<rev> correctly) + the path-scope parse — do NOT re-roll URI parsing (CLAUDE.md / Issues hazards).

• Don't regress whole-tree be get or path-scoped sub-recursion get.

WIP

Design decisions

• (open) Route get with a non-empty u->path + a rev to a single-blob checkout

  that reuses the projector's resolve, instead of falling through to the branch ahead/behind / whole-wt path (the fall-through is what yields the ?<rev>/ branch no-op + KEEPNONE at sniff/GET.c:1711/1821).

TODOs

• Repro-first: be get <path>?<rev> on a known file/rev → assert the worktree file

  becomes that rev's blob (and a clean error when the path is absent at the rev).

• Implement the single-blob restore arm; --force overwrites a dirty path only.
• Test: per-file restore changes ONLY that path; unrelated dirty WIP untouched.

Blockers and bummers

• Pairs with GET-021 (this is its per-file materialization tool) and the

  path-scope semantics of GET-017/SUBS-018.

Outcome

• (open — filed 2026-06-16 from be get! graf/BLAME.c?f6bea1c5 → KEEPNONE)