| Comment: | annotate: order the version chain by topology, not mtime
An adversarial review found zit annotate could charge a line to the too-recent CHILD when a parent and child check-in share an identical (or non-monotone) event mtime — the chain was ordered (mtime asc, hash). Fossil orders its annotate walk by pure topology (generation number, descendants.c/diff.c), so a parent is ALWAYS processed before its child. Match that. New repostate.ancestryLinearized runs Kahn's over the reversed (child->parent) ancestry edges within the file's ancestor set, emitting newest->oldest with a (mtime desc, hash) ready-queue among topologically-INCOMPARABLE nodes, then reverses to the engine's oldest-first order — topology is now the PRIMARY key, mtime/hash only orders incomparable versions. annotateFile consumes it in place of the old sort; the attribute engine (primary-parent pass-through, oldest origin, binary refusal, layout) is unchanged. Amends the RESOLVED annotate-attribution rule. Linear/monotone history is byte-identical (degenerates to mtime-ascending); new tests (same-mtime parent-first, non-monotone, merge primary-parent) fail against the old order. 1678 unit + 376 e2e green. |
|---|---|
| Timelines: | family | ancestors | descendants | both | cli |
| Files: | files | file ages | folders |
| SHA3-256: |
ff9662dfee2cc41f492dbbed354d8321 |
| User & Date: | dmestas on 2026-07-18 16:44:18.425 |
| Other Links: | branch diff | manifest | tags |
|
2026-07-18
| ||
| 16:58 |
info: render the cherrypick/backout provenance from the Q card (B-merge-41)
zit info on a cherrypick or backout check-in now shows a provenance line derived from the parsed 4.7.14 Q card: a 'cherrypick:' line for Q plus and a 'backout:' line for Q minus, each carrying the full REV hash, placed right after the parent and merge lines with the value column aligned. It reads through the shipped artifact parse path (repo.manifest then artifact.parse then parseQCard, iterating manifest.q) — no bespoke re-parse. A check-in with no Q card prints no such line and is byte-identical to before. Also fixes an allocator-symmetry bug uncovered here: renderInfo now threads gpa (was arena) so info's manifest frees against the same allocator, ending an Invalid free panic at repo.deinit on every info call. Closes the last deferred clause of the cli-verbs-2 slice. 1678 unit + 376 e2e green. check-in: 4b1be918ab user: dmestas tags: cli | |
| 16:44 |
annotate: order the version chain by topology, not mtime
An adversarial review found zit annotate could charge a line to the too-recent CHILD when a parent and child check-in share an identical (or non-monotone) event mtime — the chain was ordered (mtime asc, hash). Fossil orders its annotate walk by pure topology (generation number, descendants.c/diff.c), so a parent is ALWAYS processed before its child. Match that. New repostate.ancestryLinearized runs Kahn's over the reversed (child->parent) ancestry edges within the file's ancestor set, emitting newest->oldest with a (mtime desc, hash) ready-queue among topologically-INCOMPARABLE nodes, then reverses to the engine's oldest-first order — topology is now the PRIMARY key, mtime/hash only orders incomparable versions. annotateFile consumes it in place of the old sort; the attribute engine (primary-parent pass-through, oldest origin, binary refusal, layout) is unchanged. Amends the RESOLVED annotate-attribution rule. Linear/monotone history is byte-identical (degenerates to mtime-ascending); new tests (same-mtime parent-first, non-monotone, merge primary-parent) fail against the old order. 1678 unit + 376 e2e green. check-in: ff9662dfee user: dmestas tags: cli | |
| 16:23 |
Add the addremove command: one sweep, add every extra and drop every missing
zit addremove [--dry-run] — checkout-layer convenience (fossil/hg parity; git add -A). ONE scan via the shipped extras.sweep (the exact untracked/exclusion walk zit extras and zit clean use) is the ADD set; every managed file absent from disk (no-follow stat, as status checks) is the REMOVE set. Both mutate the managed set through the shipped ManagedSet.insert/remove/write (write-temp + fsync + rename) — no second walker, no ad-hoc mutation. A present-but-modified file is never touched; control/never-tracked names are never added. --dry-run leaves .zit-managed byte-identical and prints the same report (ADDED block then REMOVED block, each ascending, root-relative). 1675 unit + 374 e2e green. check-in: f0dc5f4e2a user: dmestas tags: cli | |