Changes touching this path
- loot propose --show resolves the whole change id loot propose --list prints for a proposal whose stack this position never pulled: --list prints the id as k-z letters, and --show matched letters only against the local graph, so the handle copied off --list refused unless the stack was held. a whole change id, in hex digits or in letters, now decodes on its own through hex::decode_letters_array, the inverse of hex::letters, before the local resolver, which still takes a shorter prefix or a selector; the resolver doc said --list prints the hex id and now states the property it relies on. nothing is fetched or pulled as a side effect, and propose has no porcelain or json output, so no machine shape moves. pinned through the spawned binary: a fresh repo with its own key reads a metadata-public repo, copies the handle off --list, loot evolog refuses that handle, so this position holds no change by it, and --show reads the proposal. red first (0 passed and 1 failed), and red with each piece undone, counts read each time, each restored green: the letters arm dropped (0 and 1), the decoder nibbles swapped (0 and 1 on the codec pin, and 0 and 1 through the binary, where the forge answers that no such proposal is visible). the workspace suite is green (4521 passed over 139 binaries, 13 ignored). client-only, so it owes no deploy and is live once the CLI is released (#2339)
01737140 · dbf3dbe6…
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.