Artifact 9469b91aa3b16d77afd43fbda3b94d1ddbd72f6026bb7ed731a5c8f030e19534:
- File
docs/site/content/docs/sparse-and-horizons.md
-
2026-10-23 03:03:06
— part of check-in
[263de5a736]
on branch feat/horizon-cones
— fix(merge): refuse a merge whose ancestry crosses the horizon without a peer
draft-fossil-horizon-00 ยง5.5 has a structural clone ask the origin for the base whenever either side's ancestry crosses the horizon, even when its own walk finds a common ancestor: over part of the graph that ancestor need not be the nearest. Without a peer Checkout.Merge and Repo.Merge refused only when the walk itself crossed, and merged over a held base whose sides' ancestry crossed below it.
Both now refuse such a merge with an error matching ErrBelowHorizon that names the horizon and points to Checkout.MergeContext with a Peer; MergeContext refuses the same way when the origin does not answer. A merge whose ancestry stays above the horizon, or one given its base, still merges locally. The CLI's merge already falls back to asking the remote on ErrBelowHorizon, so it now asks in these cases too. (user: [email protected], size: 17352) [annotate] [blame] [check-ins using]
-
2026-10-23 03:28:00
— part of check-in
[c4b191ed05]
on branch feat/horizon-cones
— Merge branch 'wip/hz-close-sync' into feat/horizon-cones
An origin answering a horizon request never sends a cluster, even one a gimme names; an origin may name a history URL in horizon-served (horizon-history-url), which the client reports; and a merge with no peer to ask refuses whenever either side's ancestry crosses the horizon. Conflicts in the changelog and the CLI horizon tests kept both sides. (user: [email protected], size: 17352) [annotate] [blame] [check-ins using]
-
2026-10-23 03:03:06
— part of check-in
[263de5a736]
on branch feat/horizon-cones
— fix(merge): refuse a merge whose ancestry crosses the horizon without a peer