| Comment: | Accepted. A revision cannot go stale; a rendered row can. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
105cfb9c1839700cfcff9cf4bf2a752f |
| User & Date: | dmestas on 2026-08-26 12:44:12.920 |
| Other Links: | manifest | tags |
|
2026-08-26
| ||
| 12:58 | Accepted. Ordering by the DAG, one current landing per branch, and a verdict that was already an artifact. check-in: db0ed60824 user: dmestas tags: trunk | |
| 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 | |
| 12:43 |
Timeline: a revision signal, not rendered rows
The stream carried the filter it was opened with, so every later tick repainted the reader's page with a view they had left. That is not a bug that gets fixed once — it shipped, was fixed this morning, and would come back the next time a default moved, because the shape makes it possible. The fleet page was rebuilt around a revision number for this reason. The timeline now follows: the signal says THAT the repository changed, the client re-requests the listing and sends its own controls with it. Nothing can capture a filter and outlive it. A fragment is delivered as SSE but is a render, so it is marked and still measured — otherwise the refresh path would have been the one route the ops panel could not see. closed check-in: 0f1c202c58 user: dmestas tags: tl-rev | |
| 12:41 |
A settled landing diffs against its fork, not the moving tip
An accepted landing showed an empty Changes section. Not an error — the right answer to a question nobody was asking. While a landing is OPEN the useful base is the target's current tip: what would merging this change now. ForkPoint's comment says as much and calls the distinction deliberate. But once the record is SETTLED the branch is already contained in the target, so that question has a degenerate answer, and the only reading left is historical: what did this branch do. That is the fork point. Base is chosen by state now. On the record that prompted this, the diff goes from 0 files to 12. Second defect in the same block: the else branch says it exists so an empty Changes section never reads as 'no changes', but it only fires when the invoke FAILS. A call that succeeded and found nothing fell through to the success path and rendered exactly that blank. It now says so, naming both check-ins. check-in: 469dbab422 user: dmestas tags: trunk | |