Parents and children of check-in [21fde3240d]
|
2026-08-26
| ||
| 12:53 |
One open landing per branch: refuse the second, and agree which wins
zit#127 left this as 'probably yes, refused by name on the second' and neither side enforced it, so two threads naming one branch produced two open landings with nothing saying which accept should honour. Both halves, because refusing is not enough: two peers can each open one in separate clones and both are valid artifacts when they meet. landing.open refuses by name; the fold picks the newest root as current and marks the rest, recomputed each fold so a record revives if the one that displaced it is settled. Settled landings never take part — a later proposal for the same branch is a new proposal, not a correction of a finished one. Nothing is deleted; a record somebody argued in is not noise. check-in: c2930a1351 user: dmestas tags: landings-batch | |
| 12:48 |
A landing's commits in ancestry order, not date order
The page listed the branch through the timeline, which orders by (date DESC, hash DESC). Two check-ins in the same second tie on date and then order by hash, which has nothing to do with which is the parent. Commits land back-to-back here routinely. zit hit this in landing show and its fix is the one to inherit: the verb owns no ancestry ordering of its own. A recursive walk from the branch tip, ordered by longest path back, stopping where the branch diverges from its target. The test commits three times in one second with hashes whose order is the reverse of ancestry — the old sort gets it exactly backwards and looks plausible doing it. check-in: 21fde3240d user: dmestas tags: landings-batch | |
| 12:44 | Accepted. A revision cannot go stale; a rendered row can. check-in: 105cfb9c18 user: dmestas tags: trunk | |