Artifact 948d011aa3702065f37590d1b5d9c8be149a439926e944f5015722f11a6c85aa:
- File docs/RELEASE-NOTES-0.3.41.md — part of check-in [408e03e8d7] at 2026-10-08 22:10:49 on branch trunk — Release 0.3.41 (user: dmestas, size: 2916) [annotate] [blame] [check-ins using]
zit 0.3.41
zit 0.3.41 makes the crosslink line counts opt-in. A forge that shows
"+15 −3" on its timeline asks for them with zit crosslink --lines; every
other caller gets the stream 0.3.39 printed, at 0.3.39's cost. And
zit merge-tree --commit now records a clean merge, so a forge can merge
from the web without a checkout.
No artifact, tag namespace, wire, or on-disk repository format changed. The
crosslink record format is still crosslink 1.
Action for forge clients
If you read lines lines from zit crosslink, add --lines to the call.
Without it, 0.3.41 prints no lines lines at all. A consumer that does not
read them needs no change.
Line counts are opt-in
0.3.40 counted every changed file of every check-in the first time
crosslink ran over a repository, whether or not the caller wanted the
counts. On a long history that first run took many times longer than it
used to. Now:
zit crosslinkcounts nothing, prints nolineslines, and reads and writes no line-count cache.zit crosslink --linesprints them exactly as 0.3.40 did: the countszit diff --numstat --checkingives,- -for a binary file,0 0for a mode-only change, and nolinesline when the store cannot produce a side's content.- A cache written by 0.3.40 is reused as it is.
A shun no longer recounts everything
A check-in's counts are fixed by its name, so they are counted once. Under
0.3.40 a shun threw every stored count away. Now a shun recounts only the
check-ins that touch a path a shunned blob was written to: the check-in that
wrote it, and any later one that read it as the parent side. Those lose the
lines line for that file; everything else is served as stored.
The one exception is a history that holds a check-in whose changed files are unknown. A shunned blob could sit at a path nothing records, so the counts are taken again in full.
merge-tree --commit records a clean merge
Before, --commit recorded a merge only when it had conflicts to settle,
and refused a clean one with "there is nothing to resolve". The clean case
is the common one, and it had no path that worked on the store alone. Now:
zit merge-tree feat --into trunk --commit -m "merge feat" --user u \
--expect-current TRUNK_TIP --expect-other FEAT_TIP
records the merge on trunk, the check-in zit merge feat && zit commit
would make in a checkout of trunk. --expect-current and --expect-other
still guard it, and any --resolved file or --delete path is refused,
since nothing conflicts. The source may be any check-in, not only a branch
tip.
Compatibility
zit crosslinkwithout--linesis byte-identical to 0.3.39.zit crosslink --linesis byte-identical to 0.3.40, except for files a shun has made uncountable.--lines --no-cachestill matches the cached run byte for byte.merge-tree --commiton a conflicting pair is unchanged.