isomorphic-jj 1.10.0 → 1.12.0

package/CHANGELOG.md

@@ -1,5 +1,212 @@
 # Changelog
 
+## 1.12.0 — 2026-09-27 — op-recording gaps left by #43/#45's fixes (#48)
+
+Follow-up to #43/#45 (below). Walking every op backward then forward now
+lands correctly in 49 of 60 restores (up from before); the 11 misses were
+five distinct gaps, all in the operation-recording machinery those fixes
+introduced or depend on, plus one pre-existing bug in `operations.list()`
+discovered while writing regression tests for the others.
+
+### Fixed
+
+- **The descendant rebase performed by `edit()`/`snapshot()`/
+  `autoSnapshotWorkingCopy()` was never itself recorded in the operation
+  (R1).** `_rebuildDescendants()` mutates every rebased descendant via
+  `graph.updateChange()`, but had no way to hand its callers each
+  descendant's pre-rebase state — so `undo()`/`operations.restore()` had
+  nothing to reverse the rebase with, even though the ANCESTOR's own
+  content change was (already) correctly captured. Added an optional 4th
+  parameter, `outChangeSnapshot`, populated with `{[descendantId]:
+  fullRecordBeforeRebuild}` for every descendant actually mutated; all
+  three call sites now pass their own `changeSnapshot` object through so
+  it lands in the same operation record.
+- **Restoring to a `conflicts.resolve()` (or `merge()`/`converge()`/
+  `moveChange()`) op could restore the resolved file but leave the
+  change's conflict state unresolved (R2).** `computeGraphReversal()`
+  recovers "conflict state right after `landingOp`" by scanning for a
+  LATER op's own "before" snapshot — which only exists if some later op
+  also touches conflicts. Conflict resolution is usually a one-off event
+  with nothing later re-touching the `ConflictModel` at all, so landing
+  exactly on it found no candidate and silently left whatever conflict
+  state already happened to be live untouched (file content usually
+  recovered correctly anyway, by coincidence — some unrelated later op
+  touching the same file's `changeSnapshot`). `conflicts.resolve()`,
+  `merge()`, `converge()` (unresolved case), and `moveChange()` now also
+  record `conflictsSnapshotAfter` — the result of the mutation THEY
+  performed — and `computeGraphReversal()` falls back to it when nothing
+  later reveals the answer.
+- **A file changed directly on disk and picked up by
+  `autoSnapshotWorkingCopy()` (not the explicit `snapshot()` API) had no
+  "before" copy recorded anywhere (R3) — described as "silent
+  re-snapshot" when it also rebases descendants.** `autoSnapshotWorkingCopy()`
+  — the implicit reconciliation `status()`/`read()`/`describe()`/etc.
+  trigger on every call — mutated the graph (and rebased descendants) with
+  no operation recorded at all. A later `undo()`/`operations.restore()`
+  had nothing to reverse it with, and since the same function runs again
+  on every subsequent call with no drift left to detect, a real,
+  one-time content change looked exactly like it had simply never
+  happened. Now records a real operation (mirroring the explicit
+  `snapshot()` API, `description: 'auto-snapshot working copy'`) whenever
+  it actually refreshes content — gated on the same `added`/`modified`/
+  `deleted` check it already uses, so a no-op call still records nothing.
+- **After `edit()` moves `@` to an older change, `log()` could hide a real,
+  undescribed tip with real work in it, and `edit()` recorded only its own
+  target in `view.heads`.** `_computeHiddenOrphans`'s `autoCreated ||`
+  branch (needed for two undo-artifact cases — see its doc comment) has no
+  way to distinguish "a synthetic scaffolding change that's still
+  discardable" from "a real, live tip the user simply isn't checked out on
+  right now" once the FLAG is set once at creation and never cleared.
+  `edit()` recording only its own target in `view.heads` (correct back
+  when `edit()` was a pure checkout, wrong now that it also commits the
+  change being left) meant this package's own "explicit, maintained set of
+  live heads" proxy never saw the other, real tip at all. Fixed two ways:
+  `edit()`'s recorded `view.heads` now uses `computeCurrentHeads()` (every
+  non-abandoned change with no non-abandoned children) instead of
+  `[args.changeId]`; and `RevsetEngine` now takes the operation log as a
+  constructor param and `_computeHiddenOrphans` adds the latest op's
+  `view.heads` to its `trackedHeads` signal, alongside the working-copy
+  pointer and every bookmark/tag target — the "explicit, maintained set of
+  heads" this package's own doc comment already said real jj's View keeps,
+  now actually wired through.
+- **`operations.list()` reversed its own internal array in place instead
+  of a copy, silently scrambling operation order on the SECOND call within
+  a session.** `oplog.list()` returns its live internal array by
+  reference (by design — `computeGraphReversal()` and others need the
+  real, oldest-first list); `operations.list()`'s own `.reverse()` (to
+  present newest-first) mutated that same array as a side effect. Calling
+  it twice — a completely reasonable thing to do (list history, do
+  something, list history again) — un-reversed it back to oldest-first,
+  and anything recorded via `oplog.recordOperation()` in between landed
+  appended to what was, at that moment, the WRONG end. Found while writing
+  a regression test for the fixes above (two `operations.list()` calls
+  around one `autoSnapshotWorkingCopy()`), not from the issue's own repro
+  — but real and, in principle, capable of corrupting `undo()`/`redo()`/
+  `operations.restore()` for any caller that also calls
+  `jj.operations.list()` earlier in the same session. Fixed by copying
+  before reversing.
+
+  See `tests/integration/issue-43-restore-reliability.test.js`'s new
+  "issue #48" suites (8 new tests across all five gaps above) and
+  `tests/unit/core/revset-branches-coverage.test.js`'s new oplog-signal
+  suite (2 tests) for the hidden-tips fix specifically. All verified with
+  a negative control: reverting just the source changes fails exactly
+  these new tests while every pre-existing test still passes, confirming
+  they exercise real behavior rather than being tautological.
+
+## 1.11.0 — 2026-09-26 — edit() of an older change rebases its descendants (#45)
+
+Part 5 of #43 (parts 1-4 shipped in 1.10.0 / #44), previously punted because
+an initial attempt broke `tests/integration/absorb.test.js`'s "should work
+after edit()" test.
+
+### Fixed
+
+- **`snapshot()` and `autoSnapshotWorkingCopy()` now propagate an edited
+  non-leaf change's new content onto its descendants (#45).** `edit()`
+  itself never touches content — it's a pure checkout (moves `@`, syncs disk
+  to the target's existing `fileSnapshot`). The actual moment a change's
+  *committed* content changes is inside the public `snapshot()` and the
+  internal `autoSnapshotWorkingCopy()`, which reconcile on-disk state into
+  the CURRENT working-copy change's `fileSnapshot`. If you `edit()`'d into a
+  change that already had descendants and then modified a file, both
+  functions updated only that change's own `fileSnapshot` and never
+  propagated the update, so the descendants stayed permanently stale unless
+  you happened to `edit()` directly into one of them (which just re-synced
+  disk FROM its own still-stale snapshot — no help). Both now check for
+  descendants (`_findDescendants`) after committing the new content and, if
+  any exist, rebase them onto it (`_rebuildDescendants`) — matching real
+  jj's automatic rebase-on-edit. `edit()` was correctly left untouched: it
+  never mutates content on the way IN, so it was never the right hook point.
+- **Un-deprecated `_rebuildDescendants()` and fixed a real-content-vs-
+  synthetic-edit ordering bug in it (#45).** This line-level, three-way-
+  merge-style rebase helper had been marked `@deprecated` with zero callers
+  (`absorb()` uses a different function, `_rebuildDescendantsWithStates`) —
+  reused here instead of writing a second rebase implementation. Its first
+  pass builds "the original parent state" for every change by reading the
+  parent's CURRENT `fileSnapshot` live from the graph. Called (as it must
+  be) *after* the ancestor's own `graph.updateChange()` has already written
+  its new content, that live read captures the NEW content as if it were
+  the pre-edit baseline for the ancestor's DIRECT children — every line of
+  a stale descendant then looks like the descendant's own deliberate edit
+  (stale != "original"), so the old content gets preserved verbatim: a
+  silent no-op that reproduces the exact bug rather than fixing it. Added an
+  optional third parameter, `originalAncestorSnapshot`, that callers supply
+  with the ancestor's pre-mutation snapshot; the first pass uses it in place
+  of the live read specifically for the ancestor's direct children. Deeper
+  descendants are unaffected (their own immediate parent hasn't been mutated
+  yet when the function reads it, so the live read is correct for them).
+- **`edit()`'s OWN inline content-commit — a third site the first pass
+  missed — now propagates too (#45).** There are three places a checked-out
+  change's content actually gets committed, not two: alongside the public
+  `snapshot()` and the internal `autoSnapshotWorkingCopy()` above, `edit()`
+  has its own separate inline step that snapshots disk for the change being
+  switched AWAY FROM and commits it via `graph.updateChange()` directly —
+  entirely bypassing both other functions. The first pass explicitly left
+  `edit()` untouched, on the theory (recorded in this same entry, in an
+  earlier draft) that this site was pure checkout bookkeeping unrelated to
+  content commits, and that `tests/integration/absorb.test.js`'s "should
+  work after edit()" would therefore keep passing unmodified. Both halves of
+  that theory were wrong: this inline step *is* a real content commit (it's
+  literally how `write()`-then-`edit()`-away ever reaches the graph at all,
+  since `write()` itself only touches disk), and it needed the exact same
+  descendant-propagation treatment as the other two sites. Once added, the
+  `absorb.test.js` collision the very first attempt at #45 hit *did*
+  materialize here — confirming this was the actual site that original
+  attempt (and this issue's own motivating repro: "edit an ancestor, modify
+  it, edit back") was about all along.
+- **Fixed the `absorb.test.js` fixture, not the feature.** Traced exactly
+  why: "should work after edit()" wrote `file.txt` on `change1`, edited away
+  to `change2`, then called `absorb()` expecting it to fold `change2`'s
+  (stale) content back into `change1`. That "diff" only existed because
+  `change2` hadn't picked up `change1`'s edit — precisely the bug being
+  fixed. Once fixed, `change2` correctly matches `change1` the moment you
+  edit away, the manufactured diff disappears, and `absorb()` correctly
+  finds nothing to do. Updated the fixture to make a genuine *new* edit at
+  `change2` after returning to it, so `absorb()` has a real, bug-independent
+  diff to fold — preserving the test's actual intent ("absorb still works
+  normally in a session where an ancestor was edited earlier") without
+  depending on the bug.
+- **Fixed a second, pre-existing bug in `_rebuildDescendants()` that this
+  same follow-up surfaced: file deletions were resurrected as empty
+  strings.** The function had no way to represent "this file doesn't exist"
+  separately from "empty content" — every file was coerced with `|| ''`
+  before diffing. A descendant that deliberately deleted a file the parent
+  still has (e.g. `backout()`'s reversal change, which legitimately has no
+  `fileSnapshot` entry at all for a removed file) got that file rebuilt as
+  `''` instead of staying deleted, breaking
+  `tests/integration/backout.test.js`'s two file-addition-reversal tests.
+  This was always latent — `_rebuildDescendants()` had zero callers at all
+  before this issue gave it a real one, so the bug was never exercised.
+  Fixed by tracking each file's existence (`hasOwnProperty`, not `||`) on
+  all three sides (descendant, original parent, updated parent) and
+  handling "descendant deleted it," "descendant added it fresh," and "both
+  sides have real content" as distinct cases, rather than collapsing all of
+  them into one string-diff.
+
+### Testing
+
+New file `tests/integration/issue-43-restore-reliability.test.js`, describe
+block "issue #45": edit into a non-leaf change, modify a file, and confirm
+the descendant picks up the edit (a) via an explicit `jj.snapshot()` call,
+(b) via `autoSnapshotWorkingCopy()` triggered by `jj.status()` after an
+out-of-band disk write (a same-size `jj.write()` wouldn't reach this path —
+`write()` immediately updates the tracked mtime/size itself, so the
+disk-walk would see nothing "modified"), and (c) via `edit()`-away alone
+with no explicit `snapshot()`/`status()` call in between — all three checked
+via `jj.show()`. A fourth test confirms a leaf change (no descendants) still
+works, exercising the other side of the `descendants.length > 0` branch. A
+fifth test constructs a descendant that deliberately deleted a file and
+confirms rebuilding it preserves that deletion instead of resurrecting an
+empty string. Negative controls: with the `src/api/repository.js` changes
+reverted, the propagation tests fail with stale pre-edit content, the
+deletion test fails with a resurrected `''`, and the leaf-change test still
+passes; reapplying the fix makes all five pass, and
+`tests/integration/backout.test.js`'s two previously-broken tests pass
+again too. 1864 tests passing; lint (0 errors), format:check, typecheck,
+and build all green; all 12 `examples/*.mjs` run clean; branch coverage
+90.06% (gate: 90%).
+
 ## 1.10.0 — 2026-09-26 — operations.restore() reliability (#43)
 
 A substantial follow-up to 1.9.1/1.9.2's undo/restore work (#37/#38/#39/#41):