Artifact 4d18fcc7f84c93150977fcf7c094fd6ca5db0d17dc98a084fb0f71161517a706:
- File
cli/repo_cone.go
-
2026-10-22 14:47:23
— part of check-in
[e5904fc85b]
on branch feat/horizon-cones
— feat(horizon): expose content horizons in the public API and CLI
A store cone could carry a horizon only through internal/cone, so library users and the CLI had no way to clone into or edit a content-horizon store. Add Horizon, HorizonRule, NewHorizonCone, Cone.Horizon and Cone.WithHorizon over the internal cone (always the content cut), carry it through SetStoreCone/SetStoreConeContext (deepening fetches what the older check-in keeps) and CloneOpts.StoreCone, and add --horizon, --leaves, --no-horizon and --cone to repo clone and repo cone store.
A horizon is a property of the store, not of a checkout (draft-fossil-horizon-00 3.2), so checkout cones carrying one are refused with ErrHorizonCheckout, and widening the store from a checkout cone keeps the store's horizon. (user: [email protected], size: 11517) [annotate] [blame] [check-ins using]
-
2026-10-22 14:48:00
— part of check-in
[964b91f682]
on branch feat/horizon-cones
— Merge branch 'wip/horizon-api' into feat/horizon-cones
The public horizon API in the shape approved: a horizon is part of Cone (NewHorizonCone, Cone.Horizon, Cone.WithHorizon), store cones carry it through SetStoreCone and SetStoreConeContext and the new CloneOpts.StoreCone, checkout cones refuse it with ErrHorizonCheckout, and the CLI takes --horizon and --leaves on repo clone and repo cone store and --no-horizon on repo cone store. (user: [email protected], size: 11517) [annotate] [blame] [check-ins using]
- 2026-10-22 15:06:06 — part of check-in [ec8b4c770b] on branch feat/horizon-cones — Merge branch 'feat/horizon-cones' into wip/horizon-cursor (user: [email protected], size: 11517) [annotate] [blame] [check-ins using]
-
2026-10-22 14:47:23
— part of check-in
[e5904fc85b]
on branch feat/horizon-cones
— feat(horizon): expose content horizons in the public API and CLI