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.