4 check-ins related to "protect-4"
|
2026-08-26
| ||
| 23:51 | Landed phase 4: the rule has a page, and the page says what it costs. check-in: 8f527acdb5 user: ai-local tags: trunk | |
| 23:24 |
RFC 0007 phase 5: the matrix, driven through the forge
Every row of the RFC's table, the way a person or a client would do it: the forge's accept through the API as owner and non-owner; a clone's accept pushed through the sync gate, refused whole with the branch named, then admitted for the owner with no reply posted; a stock fossil client's merge refused; branching off trunk and pushing to an unprotected branch admitted; a forged accepted reply recorded as a claim. A branch continued past its merge stays accepted. Compatibility and disposability as the RFC states them: a clone's artifacts are identical with the row present or absent, and the record renders identically before and after the row, and across the section-11 wipe. The disabled control with its reason is proved in the web package, where a viewer has an identity — and proving it found the landing page asking MayLand about nobody: the viewer now travels with the read. Three rows are proved elsewhere and named in the file so the matrix reads complete. closed check-in: 2a68c15ebf user: dmestas tags: protect-5 | |
| 23:16 |
RFC 0007 phase 4: the settings surface, under a
Protected branches beside capabilities on the repository settings page: a branch or glob per row, owners as logins, every matching rule applies, blank the owners to remove one. The form rebuilds the stored set, so a renamed row is a delete and a write. The cost is stated where the rule is set, because both things it changes surprise someone who knows fossil: on this forge i means less than it means in fossil, and a stock client can be refused a push its capability string says it may make. Policy of this forge, outside the repository; a clone is byte-identical to an unprotected one. The section is not drawn on a forge with no policy store. closed check-in: 0d3bcdd784 user: dmestas tags: protect-4 | |
| 23:13 |
RFC 0007 phase 3: the merge is the fact; accept asks MayJoin
The fold reads accepted from the DAG, for every landing: the earliest target check-in after opening whose non-primary parent is on the proposed branch. A reply asserting acceptance with nothing merged leaves the record open and is recorded as a claim; the page says so, the timeline files it as conversation. Rejection has no DAG fact and stays the reply's to say. Re-derived after every branch recompute — which now also invalidates the count memo, since it can settle a landing — so a merge pushed from a clone with no reply settles. landing.accept refuses a non-owner on a protected target before writing, naming the owners. landing.get reports MayLand beside CanAccept so the page shows a disabled control with the reason. Fourteen existing tests settled records by reply alone, or asserted a by-hand merge does not count; each now carries the merge it announces or asserts the RFC's reading. Giving the web fixture real check-ins exposed checkin.diff dereferencing a nil store; it now refuses, after the lookups so not-found still wins. closed check-in: 4832508615 user: dmestas tags: protect-3 | |