Skip to content
zit Timeline
Login

Timeline

10 most recent check-ins occurring on or after 2026-08-25 18:50:27.

More ↑
2026-08-27
19:00
settings, config: accept -R on a bare store

Their repository and global tiers, and config's user/shun areas, all live in the store, not the working tree -- fossil serves them under -R too. Move both out of the -R blanket refusal, resolve the override, and name a bad -R path with the #97 diagnostic rather than the discovery message that advises the flag already given.

Issue #153. closed check-in: b342686fd9 user: dmestas tags: settings-config-repo-flag-153

11:04
landing: update -- bring the target into the proposed branch on the store

The reverse of accept, through the same ephemeral-checkout merge, now one function that does not know which direction it runs. Always merges in a working area of its own, checkout or not, so a tree is never left half-merged. Up to date is exit 0 with nothing written; a conflict is refused with its paths; a settled record is refused; a stacked landing is not, since refreshing a rung is what the rungs above it need. The refresh is a reply in the record's thread. Issue #152. check-in: c4b949ebbf user: dmestas tags: trunk

2026-08-26
19:43
merge serve-protected-branches: per-request branch protection behind a trusted front (#151) check-in: d46cb9a855 user: dmestas tags: trunk
16:57
serve: refuse a check-in's own singleton claim on a protected name; warm the image only after a push

A self-targeted +sym-B is not how a branch is joined, but nothing legitimate mints one on a protected name. maintain now derives the fast-read image only when the log grew, so a pull-heavy fronted server does not pay an image load per connection. Pins that a merge with a protected secondary parent stays on its primary's branch. Issue #151. closed check-in: 13760d0c92 user: dmestas tags: serve-protected-branches

16:14
serve: refuse membership changes to protected branches, per request, from a trusted front

A front that authenticates every push knows who is pushing; the store knows which branch a pushed check-in resolves to. The front sends only the rule -- X-Zit-Protect, a glob list -- and zit serve --fronted refuses the whole round when a check-in would join one of those branches or a tag would move a held check-in in or out of one. Same error card as a content-policy refusal, so a stock fossil client reads it.

Without --fronted the header is ignored and the server is unchanged. Nothing new on the wire or in the repository. Resolution is crosslink's own, through the fast-read image, which maintain keeps warm between connections. A parent not yet held is admitted: it is judged on arrival. Resolver faults fail closed. Issue #151. check-in: 63ec7d6dc8 user: dmestas tags: serve-protected-branches

14:35
merge landing-reply-to-149: --reply-to aims a landing comment's I-card (#149) check-in: 2892f40e8b user: dmestas tags: trunk
14:05
landing: --reply-to aims a comment's I-card at a post, not just the root

comment collapsed the G and I cards onto the record root, so a landing thread could not branch. Split mintForum's root and reply-to; landing comment takes --reply-to POST, resolving the thread root with the same helper forum uses and refusing a target outside the record's own thread. closed check-in: fed51b20cb user: dmestas tags: landing-reply-to-149

2026-08-25
21:19
merge rfc-vector-guard: vectors inert on disk check-in: ca7453995e user: dmestas tags: trunk
21:09
rfc vectors: keep them inert on disk

An unguarded vector parses as a real artifact, so Fossil crosslinks it into every clone -- two check-ins, a technote, twelve sub-manifest slices and a phantom pair that sync chases forever. Each vector now carries a leading # block; rfc_vectors.zig strips it at comptime so callers still see the exact RFC bytes.

Background and the cleanup that follows: see wiki page 'rfc-vector-ledger'. closed check-in: 32ef56aaf4 user: dmestas tags: rfc-vector-guard

18:50
merge fix-148-prefix-lookup: byte-aligned name lookup (#148) check-in: 3f8aa36a1d user: dmestas tags: trunk
More ↓