Changes touching this path
- losing one bad file stops costing you every other uncaptured edit, because `loot restore <path>...` discards per path against the same delta seam `status` reads — and it never decrypts to decide, so a path whose recorded side is sealed, embargoed, burned or merely past its grant expiry refuses the whole run rather than clobbering the readable half beside it (#1498)
cd463799 · dbf3dbe6… - a flags value stops being read as a flag, because `FlagSpec::given` asks in flag position the way `positionals` already does and every verb-local scan in both binaries is deleted behind a census that refuses the shape — which is what had `loot tag -m "-d"` signing a retirement, `loot describe -m "--no-snapshot"` silently skipping the capture, and `loot-first land --allow-publish "--skip-tests"` skipping the gate that is its whole job (#1612)
b40e1843 · dbf3dbe6…diff - loot 0.4.19: the Known Issues page is re-read against the binary it now names by running it rather than re-reading its source, the six entries pin 5 held leave on the release that finally carries their fixes, and the pin retires with its emptied table on its own instruction — the re-run is what caught the evolog entry rotting without an edit, because loot log grew a when column somewhere in this range and the entry had claimed for two releases that evolog was the only time the CLI prints, and the recovery-door note is rewritten rather than deleted since loot id phrase shipping does not change that both it and recover open the repo first; and the restore no-op test stops calling its own instrument blind when the clock is the coarse thing, because it stamped the setup write and the restore microseconds apart against a file clock that ticks every 15.6 ms — it was failing four runs in five on main, standalone, while passing inside a full suite slow enough to straddle a tick, so it now probes for a distinguishable mtime rather than sleeping a constant that would bake this filesystem granularity into the assertion
4dcc9ff6 · dbf3dbe6…diff - loot restore grows --source and it is the same verb with a different base rather than a second reader or a second writer: Workspace::delta_against takes the base mirrored_delta used to hardcode, so the disclosure gate, the four-kind absence ladder and the refuse-whole rule are inherited rather than restated, and what the seam hands back is now the base TREE rather than its key set because a caller re-sealing restored content has to be able to say what the base recorded it as. AC3 is plan-then-apply: every action is materialized from verdicts that were all decided above the refusal gate, so an openable path named FIRST beside an unopenable one is not written, which is the assertion a write-as-you-go loop would fail and the pin names it in that order. Three things are decided rather than inherited. A path the SOURCE does not record is reported and its local copy kept unless --delete-absent is passed - refused without --source, where it could only be a silent no-op wearing a destructive word - but a path in neither the source nor the working tree still refuses, because that is a typo and #67 says a typo must not exit zero looking clean, and AC4s deletion half presupposes a local copy to delete. The loss sentence is a different sentence: what a --source write replaces is recorded content plus whatever uncaptured edit sat on top of it, so #1498s nothing ever recorded them would tell an operator they had lost something loot cat prints in one command. And AC6 is a sentence rather than a behaviour, which is the ticket premise that turned out wrong in the useful direction: restore writes plaintext and seals nothing, so the next capture already derives the tier from todays .lootattributes and there was no publication decision to get backwards - what was missing was the report saying so, per path and on the dry side too. Two further premises were wrong. The raw --dry-run scan #1612 replaced was correct only by a coincidence this ticket expired, since --source is the verbs first valued flag and loot restore --source --dry-run a.rs now reads --dry-run as the selectors value. And the shared recoverability sentence opened in the past tense, so a dry run printed running this without --dry-run REPLACES ... what those paths held on disk is gone - found by running the shipped binary, not by review, and the tense now lives in the real runs frame where it is true (#1499)
c193cf35 · dbf3dbe6…diff - loot show, the deletion rows of loot status and a surface listing name the published tier off the marker the object carries rather than off the .lootattributes on disk, so a published object whose rule was deleted no longer prints internal and a plain one given a rule since no longer prints published: the delta seam reads each row marker in Workspace::rows_of, off the side that carries the row, and keeps the rule for a live side (ADR 0079 section 1) and for a seal it cannot read, while the clobber guards take ResolvedDelta::classes and pay no read; surface, rehome and the pull auto-surface list through the new Workspace::with_sealed_publish_status. the status machine listing is the working tree on disk and keeps the rule. measured over a 400-path tree with the counters, every added read is a memo hit: object_gets moves by one per row with a recorded side (show of a half-edited change 1602 to 1802, status with a third deleted 804 to 938, surface --json 802 to 1203) and object_disk_reads is flat on each (601, 401, 401), a clean status is flat on both, and a hyperfine A/B over 2000 paths reads within noise (show 98.2 vs 97.3 ms, status 93.1 vs 92.6, surface --porcelain 165.4 vs 168.3, status with deletions 130.8 vs 129.8, load 0 to 6 percent). surface_object_reads counts the listing marker read apart from the opens, and the restore pin reads the seals its capture wrote. both directions pinned red first (0 passed and 2 failed with the fix undone), each through the verb: show and status deletion rows, and surface over trees ferried from git commits that delete and add a published rule. red with each piece undone, counts read each time, each restored green: the delta seam on the rule (1 passed and 1 failed), marker or rule, the overstating repair (1 and 1), the new side asked for a deletion (1 and 1), the listing on the rule (1 and 1), the listing as marker or rule (1 and 1), the guard paying the reads (0 and 2 in surface_object_reads). the published values in diff and surface machine output change for such rows and no key or column moves (ADR 0023). no format, wire or migration byte moves, so this owes no deploy. the workspace suite is green (4527 passed over 140 binaries, 13 ignored) (#2352)
0c27bd77 · dbf3dbe6…diff
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.