Beagle SCM

DIS-041: be get/patch FF-weave bails with graf err and leaves the file UNMERGED when the commits aren't indexed — the correct fallback is to INDEX the commits and RETRY

When a store-backed worktree that is BEHIND trunk is fast-forwarded (be get '?'), files that diverged on both sides need a 3-way weave. If the relevant commit DAG is not indexed, the weave drops to build_tip_weave_tunable's no-history fallback (graf/GET.c:537-548), which stamps each side's blob with its own tip hashlet so the two sides share NO baseline birth-ids → WEAVEApply matches nothing → GRAFFAIL (sniff/GET.c:748), and sniff prints merge failed … (graf err) — leaving wt content untouched, i.e. the file is left UNMERGED. The only correct fallback is to index the commits and RETRY the weave — never bail, never silently return ours. See PATCH, POST, Graf.

Input

Context

• LIVE REPRO (now on disk — the earlier investigation said this transient

  "is no longer on disk / cannot be driven through be"): FF the BE-004 store-backed worktree ~/todo/BE-004-new (cloned behind trunk) onto current trunk → be get '?' → merge failed for bro/BRO.c (graf err) and graf/BLAME.c (graf err) — leaving wt content untouched. Reproducible on demand from any behind-worktree FF where both sides touched a file.

• The (void)-ignored GRAFIndexFromTips guard (sniff/PATCH.c:1857,

  comment: "Without this the merge silently returns ours's bytes") is the smoking gun — the index step exists but its failure is swallowed.

Goals

• The FF/weave path INDEXES the needed commits (the tips' ancestry) and

  RETRIES, so a behind-worktree FF on a real divergence actually MERGES.

• No silent fallbacks: an un-indexed/empty-side weave must index+retry or

  propagate a hard error — never "leave wt untouched", never return ours.

• Acceptance = the real be get '?' operation merges the divergent files

  (demonstrated on a live behind-worktree), not "tests green".

Constraints

• Do NOT touch the weave ENGINE on a disjoint-edit premise — that is

  DISPROVEN (below). The fix is in the verb/index layer.

WIP

Design decisions

• RETRACTED (unproven, was BS): the prior conclusion "the graf err is a

  verb-layer base/target SELECTION failure" is withdrawn — it was asserted without a live repro. Diagnose from the repro now available, not theory.

• PROVEN, keep: the graf weave ENGINE merges disjoint edits

  byte-identical to git merge-file (the frozen SUBS-019 trio, 135584 B, clean via GRAFMerge3Bytes/GRAFMergeWtFile/GRAFMergeWtFileTunable). So the engine is correct; the bug is the verb dropping to the un-indexed fallback instead of indexing + retrying.

TODOs

• Repro-first: a hermetic small store + behind-worktree FF that triggers

  graf err (regression test, e.g. extend graf/test/MERGEWT01.c).

• Make the weave path index the commits and RETRY when history is absent

  (build_tip_weave_tunable / GRAFIndexFromTips); propagate index failure (drop the (void)), never leave-untouched / return-ours.

• Prove be get '?' on a real behind-worktree MERGES the divergent files.

Blockers and bummers

• Currently blocks landing BE-004 (its FF hits this); BE-004 stays unmerged

  until the FF-weave self-heals (index+retry) — NO hand-pick reconcile.

Outcome