Artifact 1ae930ec6c24fe1d7db39deaadcb5e2e4fcc68eba182b804680ae2b97d5d887f:
- File
docs/RELEASE-NOTES-0.3.25.md
— part of check-in
[726efdca6b]
at
2026-09-20 13:25:34
on branch trunk
— Release 0.3.25
A bare -- ends the options in every verb; zip names are flagged UTF-8. (user: dmestas, size: 3212) [annotate] [blame] [check-ins using]
# zit 0.3.25 zit 0.3.25 makes two kinds of name reachable again: a path that begins with a dash, and a non-ASCII name inside a zip archive. No artifact, tag namespace, sync message, or on-disk repository format changed. ## A bare `--` ends the options, in every verb A file whose name begins with `-` could not be named at all. Passed bare it parses as an option, and the usual workaround does not apply here: a path is compared literally against the check-in's file list, so `./-x.txt` parses cleanly and then resolves to nothing. A caller had two spellings and neither reached the file. Downstream, a forge serving such a repository answered 500 for every content route on it, because the `zit cat` beneath could not be spelled. Twenty parsers already honoured the marker, including the shared flag scanner behind `add`, `rm`, `commit` and `mv`, so those verbs were never affected. Twenty-five had hand-written argument loops that did not, and `cat`, `annotate`, `log`, `ls`, `grep`, `archive` and the sync verbs were among them. Each now gates its option branches behind the marker: once the option branches stop matching, an operand falls through to the positional handling that was already there, so `-n` after `--` is a name rather than a limit flag, and no verb grew a second copy of its own operand logic. Three tests pinned the old behaviour and now pin the new one. A second `--` is an ordinary operand rather than another marker. The marker is documented as its own help topic, `zit help options`, rather than as an options row in thirty-nine verbs' help. It is not a verb's option; it is the rule every verb parses by. A leading `./` is still matched literally, deliberately. Normalizing it would help a path and leave a branch or tag name beginning with a dash just as unreachable, and the marker covers both. ## Zip archives flag their names as UTF-8 `zit zip` wrote member names as UTF-8 bytes and never set general-purpose bit 11, the flag that says so. A conforming reader must then decode the name as CP437, so a committed `café.txt` extracted as `caf├⌐.txt` and a Japanese name came out as line-drawing characters. The bytes were always correct; only the flag was missing. Both records now take the flag from one constant. A reader trusts the central directory for metadata, so setting it on the local header alone would have left the bug in place. It is set on every member rather than only the non-ASCII ones: ASCII is a subset of UTF-8, every reader treats a flagged ASCII name identically, and one unconditional value cannot disagree with itself. Content, member order, and the data-descriptor bit are unchanged. ## Compatibility - No on-disk repository or wire format changed; Fossil RFC revision 00 remains the target. - `--` was previously reported as an unknown option by the twenty-five verbs above. Any script relying on that diagnostic sees the token consumed instead. - Archives written by earlier versions are still readable; their names were never wrong on disk, only mislabelled. ## Qualification `zig fmt --check`, `zig build test`, `e2e`, `smoke`, `muscle`, `git-import-e2e`, `git-export-e2e`, `dst`, and `cross`, plus the three-runner CI battery.