index/weave.js:238:KB-258 opens a fresh abc.ram("CFOLD", 16 MB) and folds again
for every rev above the floor, quadratic in layers. On ~/src/linux
kernel/sched/core.c (444 layers) costs 188 s and 880 MB; even a 100-rev span
costs 162 s, and LAYER_CAP 1024 allows twice that PER CHANGED PATH, so a
spanning bee diff on a real repo is unusable. view/diff.js:380:iO twoHex
takes exactly two words, so there is no path-scoped two-tip diff to fall back
on. Found in the 2026-09-18 index review.
A layer budget in the tens with the existing re-root as the default beyond it,
or a cached per-path weave; add diff <a> <b> <path>.
The budget, not a cache: LAYER_CAP drops 1024 -> 32 and the
re-root that already stood there becomes the ordinary answer.
A cached per-path weave would have to be invalidated per tip
pair and still folds once, so it buys nothing for a two-tip
diff; the budget is the whole of the cost. Past it the weave
is still one weave with real commit ids, only rooted at the
from side, so the tokens blame that rev instead of the 441
revs between — the price of the budget, stated in one log
line per run rather than one per changed path.
diff <a> <b> <path> scopes the SAME two-tip form: the third
word is root-relative like log's, matched as that path or
that subtree (never a bare prefix), and it is never stat'ed,
since neither tip need be checked out.
kernel/sched/core.c, 441 revs above the floor, tips 530bfad1 -> a142da0b on ~/src/linux, weave + emit: