10 most recent check-ins occurring on or after 2026-08-24 00:31:18.
More ↑
|
2026-08-24
| ||
| 11:27 | merge update-dirty-tree-135: carry uncommitted work across the move (#135) check-in: 5f6402dd84 user: dmestas tags: trunk | |
| 11:15 | merge landing-title-138: first line of -m is the landing title (#138) check-in: da4fa8dcbe user: dmestas tags: trunk | |
| 11:06 |
landing open: the first line of -m is the title, the rest is the prose
The whole message went into the H card and the body both, so a multi-paragraph -m minted a multi-paragraph heading and carried the same text twice. An H card is one token (§4.7.7). The split is at the first newline, not the first blank line, so a two-line message cannot mint a two-line title either. ls and show read only a title's first line: landings minted before this are immutable, so a reader has to cope with them, not merely stop making more. A message with no title line is refused before the branch lookups and the store scan. Fixes #138 closed check-in: 3e565c1caa user: dmestas tags: landing-title-138 | |
| 10:16 |
update: carry uncommitted work across the move instead of refusing it
A dirty tree is now three-way merged (current check-in, working file, target) rather than rejected, so a branch tip that advanced under uncommitted work can be joined. Previously update, merge and stash all refused that state, leaving commit --allow-fork as the only exit -- the guard that keeps forks deliberate was manufacturing them. The fork guard itself is unchanged. applyCheckinWith scans the tree once and calls back for the merge policy; handing carries in instead would scan every clean update twice, which cost a 20k-file no-op update 63%. Paths that cannot merge either way (type change, edited here / deleted there) are named and refused before anything mutates. Fixes #135 closed check-in: 7fcc9b5ee1 user: dmestas tags: update-dirty-tree-135 | |
| 02:26 | merge merge-probe: mergeability for a caller-named pair (#134) check-in: 83734fcc3d user: dmestas tags: trunk | |
| 02:17 |
merge --probe: mergeability for a pair the caller names (#134)
landing show answers the same question but must find the record first, which is a full-store walk. A consumer with its own index already knows the record and both tips; --probe lets it ask about the pair and pay only for the merge. Release build on a 20MB store: 0.01s against 0.90s. Writes nothing, never autosyncs, and exits 0 whatever the answer -- 'has conflicts' is an answer, not a failure, so a caller reads the line rather than the status. Being a read it takes -R, and then --into is required because there is no checkout to supply the other side. The probe moves out of landing and next to the merge engine: one implementation, three callers. A real merge now refuses -R by name instead of failing as a discovery miss that tells you to pass the flag you just passed. closed check-in: aff1d04310 user: dmestas tags: merge-probe | |
| 01:35 | merge diff-ignore-ws: zit diff -w ignores whitespace-only changes (#130) check-in: f863b8d6ef user: dmestas tags: trunk | |
| 00:52 |
diff: -w ignores whitespace-only changes (#130)
Lines differing only in whitespace compare equal, so a reindent or a CRLF/LF normalization produces no hunks and drops the file from --brief entirely. Comparison only: a line that does survive is emitted with its original bytes. --brief reads content under -w, which it otherwise never does, and runs the same unified() the hunk path runs so the two cannot disagree about whether a file changed. A no-hunk result now claims 'mode changed' only on real byte equality -- with -w it also means a difference that was ignored. closed check-in: 23784ef673 user: dmestas tags: diff-ignore-ws | |
| 00:41 | merge ncard-rule: fossil's per-type N card write rule (#136) check-in: 7f9f9f8927 user: dmestas tags: trunk | |
| 00:31 |
N card: follow fossil's per-type write rule (#136)
landing hardcoded N text/plain with no way to say otherwise, overriding the text/x-fossil-wiki default of artifact-format 4.7.12 on every record it wrote. It now takes --mimetype and, minting a forum artifact, follows forum's rule. The wider bug was in what landing copied. Verified against fossil's source: wiki (wiki.c:2084) and forum (forum.c:1784) write N only when the mimetype is present, non-empty and NOT the default; technote (event.c:284) writes it whenever non-empty, with no suppression. zit wrote it unconditionally for all three, so an explicit --mimetype text/x-fossil-wiki minted different bytes, and a different artifact id, than fossil produces from the same input. The draft states the READ default, not when the card is written. Only the source shows the suppression, and only the source shows that the three types disagree -- so tests pin the divergence rather than tidying it away. closed check-in: baa15c3362 user: dmestas tags: ncard-rule | |