isomorphic-jj 1.9.0 → 1.10.0

package/CHANGELOG.md

@@ -1,5 +1,280 @@
 # Changelog
 
+## 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):
+five distinct gaps that all fed the same root symptom — `operations.restore()`
+(and `undo()`/`redo()`) not reliably reproducing the repository state at an
+arbitrary past operation. Grouped into one minor release because all five
+touch the same reversal machinery (`computeGraphReversal()`/
+`applyGraphReversal()`, the `all()` revset's orphan filter, and the conflict
+model), and because two of the fixes are real behavioral changes (`log()`'s
+default visibility, and what `rebase()` actually writes into a conflicted
+file) rather than pure bugfixes.
+
+### Fixed
+
+- **`write()` and `snapshot()` now record their own operation (#43 part 1).**
+  Both mutated the working copy (disk content, and for `snapshot()` the
+  working-copy change's `fileSnapshot` too) without ever calling
+  `oplog.recordOperation()`. An edit typed into a change's working copy via
+  either was therefore completely invisible to `undo()`/`operations.restore()`
+  — the change kept its post-edit content forever regardless of which
+  operation you restored to, because there was no oplog entry to target and
+  no "before" snapshot for `computeGraphReversal()` to find. Both now follow
+  the same "snapshot the before-state, then record" pattern every other
+  mutator in this file already uses (see `describe()`), including a
+  `changeSnapshot` for `snapshot()` (which mutates a `ChangeGraph` node in
+  place) and a `view.fileSnapshot` for both.
+- **`squash()`, `rebase()`/`moveChange()`, and `abandon()` now record a
+  "files before" snapshot as part of their own operation (#43 part 1).**
+  `computeGraphReversal()` reconstructs "the state right after operation X"
+  by scanning forward from X for the first LATER operation that recorded a
+  `view.fileSnapshot` "before" value. These three operations never recorded
+  one, so restoring to a point right before one of them ran had nothing
+  accurate to fall back on: the scan would skip straight over the gap and
+  either find nothing (leaving disk untouched) or land on a much later,
+  unrelated operation's "before" value — the wrong point in time entirely.
+  Reproduced via a stack-walk (build a chain of describe/new/write/squash/
+  describe operations, `operations.restore()` to every operation in it, and
+  compare on-disk files against an independently-tracked expectation) — this
+  is what surfaces as "a forward restore to an earlier op loses a file that
+  was added between a squash and the target". All three now capture disk
+  state before mutating anything and include it in their own `view`.
+- **`undo()`/`redo()`/`operations.restore()` now record disk state right
+  before THEMSELVES ran, not the landing/target operation's own "before"
+  value (#43 part 1).** All three used to record `view: landingView` (or
+  `redoneView`/`targetOp.view`) verbatim — reusing that OTHER operation's
+  own recorded `fileSnapshot`, which represents disk state before THAT
+  operation ran, not before this undo/redo/restore call mutated anything.
+  A later `restore()`/`undo()` scanning forward past one of these would then
+  pick up that stale, wrong snapshot. Each now captures its own disk state
+  immediately before applying its reversal and merges it into the pointer
+  fields (`workingCopy`/`heads`/`bookmarks`) it still legitimately inherits
+  from the landing operation.
+- **`view.heads` no longer silently drops live heads (#43 part 1).** Every
+  operation that recorded `view.heads` hand-wrote it as either `[]` or a
+  single changeId — whatever that specific call happened to touch —
+  instead of the repository's actual current head set. `squash()` in
+  particular recorded the destination changeId even when squashing the
+  working copy creates a fresh new tip on top of it (so `heads` pointed at
+  the parent, not the tip), and any operation that didn't itself touch an
+  untouched sibling branch silently reported only one head where two
+  existed. Added `computeCurrentHeads()` (every non-abandoned change with no
+  non-abandoned child) and switched `squash()`/`rebase()`/`moveChange()`/
+  `abandon()`/`conflicts.resolve()` to use it.
+- **`log()` now hides orphans that are purely internal rewrite/undo
+  artifacts, even once they differ from their reverted parent (#43 part 2).**
+  The #37(b) fix hid an orphan only while it stayed exactly empty relative
+  to its CURRENT parent. Two shapes slip past that once undo() is involved:
+  (a) `squash()`'s synthetic post-squash `@`, if that squash is later undone
+  and the same undo reverts the destination's content out from under it —
+  the orphan's frozen (post-squash) `fileSnapshot` no longer matches the
+  destination's (reverted, pre-squash) one, even though nothing about the
+  orphan itself changed; (b) `new()`'s freshly created change, if something
+  writes into it before an `undo()` unwinds back past the `new()`. Both
+  `squash()`'s synthetic working-copy change and `new()`'s created change
+  are now tagged `autoCreated: true` at creation, and the revset engine's
+  `_computeHiddenOrphans()` hides an unreachable, undescribed change if it's
+  EITHER still empty relative to its parent OR `autoCreated` — the latter
+  doesn't need to re-diff against a parent that may no longer resemble what
+  the change was actually created from.
+- **`rebase()`/`moveChange()` now writes real conflict-marker text into the
+  working copy instead of leaving the pre-rebase ("ours") content verbatim
+  (#43 part 3) — behavioral change.** Rebase already recorded a detected
+  conflict correctly as data (via `conflicts.addConflict()`), but never
+  touched the file's actual content: `change.fileSnapshot` (and, when the
+  rebased change was checked out, the on-disk file) kept showing whatever
+  content it had before the rebase, with no indication a conflict existed
+  short of calling `conflicts.list()` separately. It now calls
+  `jj.conflicts.markers()` for each detected conflict (reusing that
+  existing marker-formatting logic rather than re-deriving it a second way)
+  and writes the result into both `change.fileSnapshot` and, when
+  applicable, the working copy on disk.
+- **`conflicts.resolve()` now records an operation, so a resolution can be
+  undone (#43 part 4).** It wrote the resolved content straight to disk and
+  mutated the `ConflictModel`'s persisted state directly, with no
+  `oplog.recordOperation()` call at all — resolving a conflict was
+  completely invisible to `undo()`/`operations.restore()`. It now captures
+  a `changeSnapshot` of the working-copy change, a `conflictsSnapshot` of
+  the pre-resolve conflict state (deep-cloned — `resolveConflict()` mutates
+  the same conflict object in place, so a naive `Object.fromEntries()` over
+  the live `Map` would otherwise leave the "before" snapshot aliased to the
+  post-mutation object), and a `view.fileSnapshot`, then records them.
+
+### Not fixed (punted)
+
+- **#43 part 5 (minor): `edit()` of a non-leaf change doesn't rebase its
+  descendants' file content.** An initial fix (propagate the edited
+  ancestor's content onto descendants when moving away from it) was
+  implemented and then reverted: it directly conflicts with `absorb()`'s own
+  job of folding a working-copy edit back into the ancestor it actually
+  belongs to — with the auto-rebase in place, `edit()` + `write()` +
+  `edit()`-away already changes the descendant before `absorb()` ever runs,
+  so `absorb()` finds nothing left to do (caught by the existing
+  `tests/integration/absorb.test.js` "should work after edit()" test).
+  Fixing this properly needs to account for that interaction; left for a
+  follow-up.
+
+### Testing
+
+1859 tests passing (12 new regression tests, matched by a new negative
+control confirming that 12 of them fail against the pre-fix code — the
+other 3 are supplementary correctness checks that already held, e.g.
+"a descendant's own edit is never clobbered"); lint (0 errors),
+format:check, typecheck, and build all still green; all 12 `examples/*.mjs`
+run clean; branch coverage 90.07% (gate: 90%). New test file:
+`tests/integration/issue-43-restore-reliability.test.js`.
+
+## 1.9.2 — 2026-09-26 — auto-snapshot mtime comparison (#41)
+
+### Fixed
+
+- **`getModifiedFiles()`/`snapshot()` no longer treat every previously-tracked
+  file as "modified" on every call (#41).** Both compared `fs.stat().mtime`
+  values with `!==`. `mtime` is a `Date`, and `fs.promises.stat()` returns a
+  fresh `Date` instance on every call — two stats of the same, unchanged file
+  are never `===`/`!==`-equal even when the underlying timestamp is
+  identical (object identity, not value equality). Fixed by normalizing both
+  sides through a new `mtimeMs()` helper before comparing, and by storing
+  tracked mtimes as plain epoch-ms numbers going forward (numbers round-trip
+  through the JSON-based `Storage` persistence exactly, unlike `Date`, which
+  serializes to an ISO string and never comes back as a `Date` on reload).
+  `mtimeMs()` deliberately duck-types the Date case (checks for a `.getTime`
+  method) rather than using `instanceof Date`: under Jest's
+  `--experimental-vm-modules`, each test file's `Date` constructor can be a
+  different realm than the one `fs`'s internal `Stats` object was built
+  with, so a real `Date` from `fs.promises.stat()` can fail `instanceof
+  Date` — silently reintroducing the exact bug this fix is for, only inside
+  the test suite that's supposed to catch it.
+
+  **Real-world impact, not just a wrong return value.** Every repository
+  created with a Git backend wraps `graph.updateChange()` in middleware that
+  syncs to Git and mints a new commit (`syncChangeToGit()`). Because
+  `autoSnapshotWorkingCopy()` — which runs before `status()`/`describe()`/
+  `diff()`/`read()`/`file.*` — treated the file list as "always modified", it
+  called `graph.updateChange()` on essentially every one of those calls even
+  when nothing on disk had changed, silently minting a spurious Git commit
+  and changing the working-copy change's `commitId` each time. This is
+  exactly what forced the `{ autoSnapshot: false }` workaround added in
+  `tests/integration/undo-restore-residuals.test.js` for issue #37(c) (see
+  PR #40) — that test's own before/after `commitId` comparisons were being
+  contaminated by these spurious commits. That workaround has been removed
+  now that the underlying bug is fixed; the test passes with auto-snapshot
+  enabled.
+
+  **Why existing tests never caught this.** The in-memory `MockFS` fixture
+  used across almost this whole test suite stores `mtime` as a plain
+  `Date.now()` number, not a `Date` instance — numbers compare by value with
+  `!==`, so `MockFS`-backed tests never exercised the object-identity bug a
+  real filesystem's `Date`-returning `stat()` hits on every call. Added
+  regression tests in `tests/unit/core/working-copy.test.js` using a
+  `RealDateStatFS` wrapper that returns a fresh `Date` instance per `stat()`
+  call (mirroring real `fs` semantics) and asserting that two consecutive
+  `getModifiedFiles()`/`snapshot()` calls with no real file changes in
+  between report zero modified/added/deleted files. Verified against a
+  negative control: reverting just the comparison fix reproduces exactly the
+  "every tracked file looks modified" symptom described in #41.
+
+### Testing
+
+1839 tests passing (2 new regression tests for #41), including the
+previously-`autoSnapshot: false`-gated issue #37(c) test now passing with
+auto-snapshot enabled; lint (0 errors), format:check, typecheck, and build
+all green; all 12 `examples/*.mjs` run clean.
+
+## 1.9.1 — 2026-09-26 — undo/restore/abandon/squash follow-ups
+
+Three bug-fix follow-ups to 1.9.0's undo/abandon/squash work (#29/#30),
+found by continued use of the same graph/working-copy machinery. Grouped
+into one patch release because all three touch overlapping code
+(`computeGraphReversal()`/`applyGraphReversal()`, the `all()` revset, and
+the synthetic-empty-change pattern `new()`/`squash()` share).
+
+### Fixed
+
+- **`restore()`/`undo()` now record their own `changeSnapshot`, so undoing
+  a restore (or undoing an undo) actually reverts something (#37a).**
+  1.9.0 taught `describe()`/`squash()`/`abandon()` to snapshot the
+  ChangeGraph state they were about to overwrite so a later `undo()` could
+  put it back — but `undo()` and `operations.restore()` themselves never
+  did the same for THEIR OWN oplog entries. Repro: `describe("old")` →
+  `describe("new")` → `restore(<op before the second describe>)` (now
+  "old") → `undo()`. Expected: back to "new". Actual: still "old", because
+  the restore's own oplog entry carried no `changeSnapshot` for
+  `computeGraphReversal()` to find — undoing it moved the working-copy
+  pointer/files but left the change record exactly as the restore had
+  left it. Both `undo()` and `restore()` now capture ground-truth "what
+  am I about to overwrite" (the same way `undo()` already did for
+  `redo()`'s benefit, under `redoChangeSnapshot`) and record it as their
+  own `changeSnapshot`. Extended `redo()` the same way for symmetry, since
+  it shares the identical gap.
+- **`log()` no longer lists changes orphaned by an undone `new()`/`squash()`
+  (#37b).** `undo()`/`redo()`/`operations.restore()` deliberately never
+  delete a change record a reverted `new()`/`squash()` created — they only
+  un-reference it (matching real jj's "hidden, not gone" model for
+  unreachable commits, and this package's own history-editing tests rely
+  on rebasing back onto one still working) — but `log()`'s default
+  `all()` revset was a flat `graph.getAll()`, so the orphan kept showing
+  up as an ordinary visible change forever. `all()`/`builtin_log()` now
+  exclude changes that are BOTH unreachable from every tracked head
+  (working copy, bookmarks, tags — the closest available proxy for real
+  jj's explicitly-maintained View heads, since this package doesn't thread
+  the operation log's `view.heads` through to the revset engine) AND
+  "discardable" (no file diff versus its own parent, and undescribed —
+  including this package's own `'(no description)'`/`'(no description
+  set)'` sentinel strings, which `new()`/`squash()` write when no message
+  is given). The change record itself is still resolvable directly by its
+  change id, matching real jj's hidden-not-gone semantics for unreachable
+  commits. Merge commits are conservatively never treated as "empty" by
+  this rule.
+- **`undo()`/`restore()` now restore the ORIGINAL commit id instead of
+  minting a new one (#37c).** Reverting a `changeSnapshot` went through
+  the same `graph.updateChange()` every normal mutation uses, which fires
+  the git-sync middleware and creates a brand-new commit from the
+  *current* tree — even though the snapshot being reapplied already
+  carried the correct, original commit id from before the reverted
+  operation ran. Since undo/restore are pure reverts, not edits, this
+  undermined the "change id survives, commit id only changes on content
+  edit" story for the revert itself. `applyGraphReversal()` (used by both
+  `undo()` and `restore()`) and `redo()`'s equivalent now write the
+  snapshot verbatim via the un-wrapped graph store, bypassing the git-sync
+  hook entirely and restoring the original commit id byte-for-byte.
+- **`abandon()` of the working-copy change now moves `@` off it (#38).**
+  `abandon(<changeId of @>)` correctly marked the change abandoned but
+  left `@` pointing at it — `status()`/`log()` kept showing the working
+  copy sitting on a change flagged abandoned. Real jj instead moves `@` to
+  a new empty change on the abandoned change's own parent(s). `abandon()`
+  now detects that case and calls `new({ parents: change.parents })` —
+  reusing `new()`'s own "create an empty change with given parents" logic
+  rather than duplicating it — which is exactly the workaround callers
+  previously had to reach for themselves.
+- **`squash()` of the working-copy change no longer gives the new `@` an
+  empty `fileSnapshot` (#39).** 1.9.0 fixed `squash()` to actually move
+  the source's file content into the destination (#30), but when the
+  squashed source WAS the working-copy change, the new `@` squash creates
+  afterward was still hard-coded to `fileSnapshot: {}` instead of starting
+  from the destination's (now-merged) tree — so `status()`/`snapshot()`
+  saw every on-disk file as untracked/new until something rewrote it and
+  triggered a fresh auto-snapshot. The new `@` now starts as a copy of the
+  destination's `fileSnapshot`, matching real `jj squash` (the new
+  working-copy change looks identical to its new parent until you touch
+  something), and the working directory is synced to match too (a no-op
+  in the common case where source's parent already was the destination,
+  but necessary whenever they aren't adjacent).
+
+### Testing
+
+1837 tests passing, including 12 new regression tests added by this pass;
+lint (0 errors), format:check, typecheck, and build all still green; all
+12 `examples/*.mjs` run clean. New test files:
+`tests/integration/undo-restore-residuals.test.js` (#37a/b/c),
+`tests/integration/abandon-working-copy.test.js` (#38),
+`tests/integration/squash-working-copy-file-snapshot.test.js` (#39). Each
+fix was verified against a negative control (reverting just that fix
+reproduces the exact wrong behavior described in its issue) before moving
+to the next.
+
 ## 1.9.0 — merge the scoped and unscoped version lineages
 
 No code change — a deliberate, one-time exception to this family's usual