Artifact efb898b167c1889eb6e8cdae6383f6af3bb84e5a47791321fa44c82aa5459d9a:
- File
www/reference.html
-
2026-08-24 19:17:25
— part of check-in
[f91105346b]
on branch strata
— landing: refuse a landing whose base was rejected or already landed
The ordering guard only looked for an OPEN base, so a rejected one slipped through and the accept SUCCEEDED -- 'accepted seg2 -> seg1', filing the work on a branch nobody would land. Nothing failed and nothing warned; the merge is fine, which is why only a rule catches it. Same hole for a base that already landed, reachable when the auto-retarget after that accept did not run.
All three cases now refuse and name the retarget that fixes them.
Documented the half of this that surprises: rejecting a landing rejects the proposal, not the code beneath a segment stacked on it. That branch descends from the rejected one and still carries its check-ins, so landing it on trunk lands them too. (user: dmestas, size: 114034) [annotate] [blame] [check-ins using]
- 2026-08-24 21:41:31 — part of check-in [2e060aa7c0] on branch trunk — merge strata: stacked landings (#144) (user: dmestas, size: 114034) [annotate] [blame] [check-ins using]
-
2026-08-24 19:17:25
— part of check-in
[f91105346b]
on branch strata
— landing: refuse a landing whose base was rejected or already landed