Skip to content
zit zit 0.3.39
Login

zit 0.3.39

zit 0.3.39 lets a forge show a conflicting merge the way zit sees it and record the author's resolution of it, both without a checkout. zit merge-tree gains -F json, which reports every conflicting file and the regions of its merge, and --commit, which records the merge with resolutions the caller supplies.

No artifact, tag namespace, wire, or on-disk repository format changed.

The merge as JSON

zit merge-tree BRANCH --into TARGET -F json

prints one JSON document and writes nothing. It gives the verdict (clean, up-to-date, conflict or unrelated), the base, current (TARGET) and other (BRANCH) check-ins, and every conflicting file. A file carries its kind (text, binary, add-add, delete-modify, modify-delete or unreadable) and each side's blob and mode, with null where the path is absent. A text file also carries the regions of the merge: same, current, other, both or conflict, each as half-open line ranges in base, current and other. The regions cover each file in order, so a page can draw all three panes and the merged result from them without merging again.

The regions come out of the same loop that produces zit's merged bytes, so the page cannot show a merge different from the one zit merge makes. The order of the names picks the sides: to show a branch as "ours", name the branch as TARGET.

The exit status is the same as without -F json: 0 clean or up to date, 5 for conflicts, 1 for unrelated check-ins. Every verdict prints a document, so a caller parses one format.

A store that lacks the content of a file both sides changed reports that file as unreadable instead of failing.

Settling a conflict

zit merge-tree BRANCH --into TARGET --commit --resolved DIR [--delete PATH]...
    -m MESSAGE [--user NAME] --expect-current HASH --expect-other HASH

records the merge of BRANCH into TARGET on TARGET's branch. DIR holds the resolved content of each conflicting path; --delete PATH resolves one by removing it. Every other path is the merge's own. The check-in is the one zit merge and zit commit in a checkout would make with the same answers, and its check-in HASH on BRANCH line goes to stdout as commit prints it.

Nothing is written when:

The merge runs in a working area of its own beside the repository, removed afterwards, and the check-in syncs the way any check-in does.

Compatibility

Qualification

zig fmt --check, zig build test, e2e, smoke (19 scenarios), git-import-e2e, git-export-e2e, dst, and every fuzz target, whose three-way merge target now also rebuilds each side of a merge from its regions, plus the three-runner battery.