Committed under a wrong description, corrected here. The message claimed this silenced an unused parameter and left two tests failing; it does neither. The content is the finished #126 fix -- appendRun honours flat, materializing the whole effective entry set rather than falling through to the S run -- and the suite is green.

The stub I described was a transient reversion in the shared checkout, made to prove the new regression test fails without the fix. It was restored before I committed. fossil commit auto-syncs, so my commit captured the restored tree while my message described the tree I had read minutes earlier.

Authored by the #126 work, not by this commit's message. check-in: 98ddd81b75 user: dmestas tags: trunk

The module doc claimed stores of this size read in milliseconds. They do not -- a 117MB mirror scanned for 62 seconds. The claim was carried over from a WRITE path taken once per ticket change onto a READ path taken per view, where neither the frequency nor the scale held. Removed rather than softened, with what the scan actually costs written down: still linear in store bytes, which the constant-factor fix did not change.

The doc also named quarry throughout. zit provides the hooks; what is built on them is not zit's business, and naming one forge in the code reads as though it were. closed check-in: 78d56a2177 user: dmestas tags: landing-doc

The fold called artifact.parse on every artifact in the store and let it fail on the content blobs, which are most of a real store's bytes -- and a parse attempt pays a whole-bytes Z checksum before rejecting one. It now applies the reject-fast pre-screen frames --structural already uses, and reuses one plaintext buffer instead of allocating per artifact.

zit landing ls, release build: quarry 1.06s -> 0.15s, zit 2.19s -> 0.31s, libfossil 8.49s -> 0.91s. A forum-shaped store is unchanged, because there is nothing to reject there; it was never the slow case.

The screen only rejects. Every accept still takes the full parse, so nothing the fold would refuse can be admitted by being shaped like a card. closed check-in: 8776c0e5bb user: dmestas tags: landing-scan

A reviewer decides from the commits before they look at a diff, and a record whose discussion the display omits is one people hold somewhere else. Both were already computed: the fold walks every reply to derive state, and the ancestry query answers the rest -- so this prints what was read and thrown away.

Ordering comes from ancestryLinearized, not mtime: two check-ins made in the same second must not invert, and the verb owns no ancestry ordering of its own. A state change renders as an event rather than a remark, so the on-the-wire marker never reaches a reader. Both lists are bounded and say when they cut. closed check-in: cff154d675 user: dmestas tags: landing-show

zit landing show reports whether a branch would land cleanly, read from the store without writing anything. zit landing accept -R lands one with no checkout, merging in a working area it creates and removes, and refuses a conflicting landing with exit 5 and nothing written. check-in: d2bbc4f459 user: dmestas tags: trunk

accept -R merges in a working area it creates and removes, materializing only the files both sides changed -- sparse-cone 4.4 resolves the rest into the record without writing them. The check-in is minted by the same commit path a checkout uses, so its F, P and R cards match a dense merge exactly.

A landing that does not merge cleanly exits 5 with the store byte-unchanged and each conflicting path named. A forge never holds a half-finished merge and never commits conflict markers; the author resolves it from their own checkout.

runMergeIn/runCommitIn take the checkout as a parameter instead of reading the process's cwd, which is what makes an ephemeral tree addressable without mutating global state. closed check-in: 8951bc9d1e user: dmestas tags: landing-bare-store

show answers whether a branch would land cleanly with no working tree and without writing anything, so a forge can flag conflicts before anyone accepts. It calls merge3.classifyFile -- the same classifier the working-tree merge runs -- so the verdict agrees with the merge rather than being a second opinion. Content-level, because hash-level resolution refuses any file touched on both sides, which is every long-lived branch. check-in: dea1cc66d3 user: dmestas tags: landing-bare-store

A landing is a forum thread plus a raw tag on the check-in that lands, so a stock fossil clone reads all of it and no new artifact kind is minted. open/ls/show/comment/accept/reject; accept merges and commits first, then records the outcome, so a partial failure leaves an open landing over merged work rather than an accepted record over an unmerged branch. check-in: c9ff7a71ea user: dmestas tags: trunk

pack no longer re-encodes profitable deltas and answers immediately on an unchanged store -- which also means a no-op pack checks no integrity, so the reference now says verify is the pass that always reads everything. stat reports the user table; verify's untouched-row list includes user rows. caching.html gains the treestat and packed memos, and the log-scan index tier says what it actually carries now. check-in: 87b58a3943 user: dmestas tags: trunk