| Comment: | merge serve-protected-branches: per-request branch protection behind a trusted front (#151) |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
d46cb9a855b2896c94c7bb1387d66bb0 |
| User & Date: | dmestas on 2026-08-26 19:43:30.287 |
| Other Links: | manifest | tags |
|
2026-08-27
| ||
| 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 | |
| 14:35 | merge landing-reply-to-149: --reply-to aims a landing comment's I-card (#149) check-in: 2892f40e8b user: dmestas tags: trunk | |