Skip to content
zit zit 0.3.25
Login

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

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.