isomorphic-jj 1.9.2 → 1.10.0

package/CHANGELOG.md

@@ -1,5 +1,131 @@
 # 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

package/dist/index.cjs

@@ -3283,11 +3283,39 @@ class RevsetEngine {
       return parentKeys.every((k) => parentSnapshot[k] === ownSnapshot[k]);
     };
 
+    // issue #43(2): the original #37(b) rule above (unreachable + isEmpty +
+    // undescribed) only hides an orphan while it still happens to have
+    // zero file diff versus its CURRENT parent. Two real shapes slip past
+    // that once undo()/operations.restore() are involved, because both are
+    // purely internal rewrite/undo artifacts that were never "empty" in
+    // any way a user would recognize — they simply never held real user
+    // content of their own, and a later revert of something else can make
+    // isEmpty() disagree even though nothing about THIS change changed:
+    //
+    //   1. squash() creates a fresh empty `@` on top of `dest` when
+    //      squashing the working copy. If that squash is later undone,
+    //      the fresh `@` becomes unreferenced — but if `dest` itself gets
+    //      reverted back to its pre-squash content by the SAME undo,
+    //      isEmpty() now compares the orphan's (frozen, post-squash)
+    //      fileSnapshot against dest's (reverted, pre-squash) one and
+    //      finds a mismatch, even though the orphan is exactly as
+    //      "discardable" as it was the instant it was created.
+    //   2. new() creates a fresh empty change on top of the previous `@`.
+    //      If something writes into it (write()/snapshot()) before an
+    //      undo() unwinds back past the new(), the orphan is left with
+    //      real file content that no longer matches its parent, even
+    //      though the user never gave it a real description.
+    //
+    // Changes created by squash()/new() are tagged `autoCreated: true` at
+    // creation (see squash()/new() in repository.js) specifically so this
+    // filter can hide them on that basis alone — still gated on being
+    // unreachable and undescribed, so a change the user actually described
+    // (or that's still live) is never hidden by this rule.
     const hidden = new Set();
     for (const change of allChanges) {
       if (
         !reachable.has(change.changeId) &&
-        isEmpty(change) &&
+        (isEmpty(change) || change.autoCreated) &&
         UNDESCRIBED.has(change.description)
       ) {
         hidden.add(change.changeId);
@@ -8087,6 +8115,38 @@ async function createJJ(options) {
     // an earlier, unrelated merge(). Fixed as part of issue #29.)
   };
 
+  /**
+   * Compute the full current set of "head" changeIds — every non-abandoned
+   * change with no non-abandoned child. Used to record an accurate
+   * `view.heads` when an operation runs (issue #43).
+   *
+   * Before this helper existed, several oplog-recording call sites
+   * (squash(), rebase()/moveChange(), abandon()) hand-wrote a single-
+   * element or empty `heads` array covering only the changeId(s) that
+   * specific call happened to touch. That silently dropped any OTHER
+   * live head the operation didn't itself touch (e.g. a sibling branch
+   * left untouched by an abandon()/squash() of a different branch — "two
+   * sibling changes report only one head between them"), and squash() in
+   * particular recorded the OLD destination changeId instead of the fresh
+   * working-copy change it creates on top of it when squashing @ ("after
+   * a squash [heads] points at the parent instead of the new tip").
+   *
+   * @returns {Promise<string[]>}
+   */
+  const computeCurrentHeads = async () => {
+    await graph.load();
+    const allChanges = await graph.getAllChanges();
+    const nonAbandoned = allChanges.filter((/** @type {any} */ c) => !c.abandoned);
+    const nonAbandonedIds = new Set(nonAbandoned.map((/** @type {any} */ c) => c.changeId));
+    const heads = [];
+    for (const change of nonAbandoned) {
+      const children = graph.getChildren(change.changeId);
+      const hasLiveChild = children.some((/** @type {string} */ id) => nonAbandonedIds.has(id));
+      if (!hasLiveChild) heads.push(change.changeId);
+    }
+    return heads;
+  };
+
   /**
    * Re-parent every child of `changeId` onto `newParents` instead — used
    * when a change is being elided from the graph (abandon(), issue #30;
@@ -8118,6 +8178,18 @@ async function createJJ(options) {
     }
   };
 
+  // NOTE (issue #43(5), punted — see PR description): an earlier version of
+  // this file added a `rebaseDescendantsOntoUpdatedParent()` helper, called
+  // from edit(), to propagate an edited ancestor's content onto descendants
+  // automatically. It was reverted: it directly conflicts with absorb()'s
+  // job (folding a working-copy edit back into an 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 (see tests/integration/absorb.test.js
+  // "should work after edit()", which regressed against this). Fixing
+  // #43(5) properly needs to account for that interaction rather than
+  // duplicate it; left for a follow-up.
+
   /**
    * Determine which operation a fresh undo() call should revert, matching
    * real jj's progressive-undo semantics (`jj-undo(1)`: "If used once after
@@ -8553,6 +8625,17 @@ async function createJJ(options) {
         });
       }
 
+      await workingCopy.load();
+
+      // Capture disk state right before this write mutates it, and record
+      // an operation for it (issue #43(1)): write() previously recorded NO
+      // operation at all, so an edit typed into a change's working copy
+      // could never be rewound by undo()/operations.restore() regardless
+      // of which op you targeted — the change kept its post-edit content
+      // forever. Mirrors the "snapshot before, record after" pattern every
+      // other mutator in this file uses (see describe(), moveChange()).
+      const fileSnapshotBefore = await snapshotFilesystem();
+
       const fullPath = `${dir}/${args.path}`;
 
       // Ensure directory exists
@@ -8568,7 +8651,6 @@ async function createJJ(options) {
       await fs.promises.writeFile(fullPath, data, 'utf8');
 
       // Track the file in working copy
-      await workingCopy.load();
       const stats = await fs.promises.stat(fullPath);
       await workingCopy.trackFile(args.path, {
         mtime: stats.mtime,
@@ -8576,6 +8658,20 @@ async function createJJ(options) {
         mode: stats.mode,
       });
 
+      await oplog.recordOperation({
+        timestamp: new Date().toISOString(),
+        user: await getUserOplogInfo(),
+        description: `write ${args.path}`,
+        parents: [],
+        view: {
+          bookmarks: {},
+          remoteBookmarks: {},
+          heads: await computeCurrentHeads(),
+          workingCopy: workingCopy.getCurrentChangeId(),
+          fileSnapshot: fileSnapshotBefore, // Store filesystem state from before this write
+        },
+      });
+
       // Return useful information about the written file
       return {
         path: args.path,
@@ -9004,6 +9100,15 @@ async function createJJ(options) {
     async moveChange(args) {
       await graph.load();
 
+      // Capture disk state right before this rebase mutates anything, so
+      // undo()/redo()/operations.restore() can rewind past it — see issue
+      // #43(1): rebase()/moveChange() previously recorded no "files
+      // before" snapshot at all, so restoring to a point right before a
+      // rebase ran had no on-disk state to fall back to and would instead
+      // pick up whatever a LATER operation happened to record (the wrong
+      // point in time).
+      const fileSnapshotBefore = await snapshotFilesystem();
+
       // Support multiple parameter names for flexibility
       const changeId = args.changeId || args.from || args.source;
       const newParent = args.newParent || args.to || args.destination;
@@ -9116,6 +9221,32 @@ async function createJJ(options) {
         await conflicts.addConflict(conflict);
       }
 
+      // Materialize real conflict-marker text into the moved change's file
+      // content — issue #43(3): rebase()/moveChange() used to record the
+      // conflict correctly as DATA (via conflicts.addConflict() above) but
+      // left the file's content exactly as it was pre-rebase ("ours"),
+      // never writing marker text into change.fileSnapshot or, when this
+      // change is the checked-out working copy, onto disk. Reuses
+      // conflicts.markers()'s own marker-formatting logic (the same format
+      // jj.conflicts.markers() already returns) instead of re-deriving
+      // marker text a second way.
+      if (detectedConflicts.length > 0) {
+        change.fileSnapshot = { ...(change.fileSnapshot || {}) };
+        const isCheckedOut = changeId === workingCopy.getCurrentChangeId();
+        for (const conflict of detectedConflicts) {
+          const markerText = await jj.conflicts.markers({ conflictId: conflict.conflictId });
+          change.fileSnapshot[conflict.path] = markerText;
+          if (isCheckedOut) {
+            const fullPath = join(dir, conflict.path);
+            const pathParts = conflict.path.split('/');
+            if (pathParts.length > 1) {
+              await mkdirp(fs, join(dir, pathParts.slice(0, -1).join('/')));
+            }
+            await fs.promises.writeFile(fullPath, markerText, 'utf8');
+          }
+        }
+      }
+
       // Update parent
       change.parents = [newParent];
       await graph.updateChange(change);
@@ -9131,8 +9262,9 @@ async function createJJ(options) {
         view: {
           bookmarks: {},
           remoteBookmarks: {},
-          heads: [],
+          heads: await computeCurrentHeads(),
           workingCopy: workingCopy.getCurrentChangeId(),
+          fileSnapshot: fileSnapshotBefore,
         },
       });
 
@@ -9587,6 +9719,16 @@ async function createJJ(options) {
         description: args.message || '(no description)',
         timestamp: new Date().toISOString(),
         fileSnapshot: initialSnapshot, // Initialize with parent's snapshot
+        // Issue #43(2): marks this as an internal, synthetic artifact
+        // rather than something the user actually created, so the revset
+        // engine's orphan-visibility filter (_computeHiddenOrphans) can
+        // still hide it after it's un-referenced by a later undo()/
+        // operations.restore(), even if some out-of-band mutation (e.g.
+        // write()+snapshot() before the undo unwinds this far) has since
+        // made it look "non-empty" relative to its parent. A real
+        // description (args.message, or a later describe()) still makes
+        // it visible regardless, via the UNDESCRIBED check.
+        autoCreated: true,
       };
 
       // Dispatch change:creating event (preventable)
@@ -9707,17 +9849,51 @@ async function createJJ(options) {
       await graph.load();
       await workingCopy.load();
       const result = await workingCopy.snapshot();
+
+      // Disk content itself is not mutated by this call (it's a read,
+      // not a write) — the same value is therefore valid both as the
+      // refreshed change.fileSnapshot AND as the recorded operation's
+      // `view.fileSnapshot` "before" value (nothing on disk changes
+      // between the two).
+      const wcId = workingCopy.getCurrentChangeId();
+      const currentDiskSnapshot = await snapshotFilesystem();
+
       // Refresh the working-copy change's content snapshot from disk.
+      /** @type {Record<string, any>} */
+      const changeSnapshot = {};
       try {
-        const wcId = workingCopy.getCurrentChangeId();
         const change = await graph.getChange(wcId);
         if (change) {
-          change.fileSnapshot = await snapshotFilesystem();
+          // Snapshot BEFORE mutating so undo()/redo()/operations.restore()
+          // can reverse this content refresh — see issue #43(1):
+          // snapshot() previously mutated `change.fileSnapshot` in place
+          // with no "before" capture and recorded no operation at all, so
+          // computeGraphReversal() had nothing to find for this changeId
+          // if a restore()/undo() landed between an out-of-band edit and
+          // the next real command.
+          changeSnapshot[wcId] = structuredClone(change);
+          change.fileSnapshot = currentDiskSnapshot;
           await graph.updateChange(change);
         }
       } catch {
         // Best-effort content refresh.
       }
+
+      await oplog.recordOperation({
+        timestamp: new Date().toISOString(),
+        user: await getUserOplogInfo(),
+        description: 'snapshot working copy',
+        parents: [],
+        changeSnapshot,
+        view: {
+          bookmarks: {},
+          remoteBookmarks: {},
+          heads: await computeCurrentHeads(),
+          workingCopy: wcId,
+          fileSnapshot: currentDiskSnapshot,
+        },
+      });
+
       return result;
     },
 
@@ -10181,8 +10357,20 @@ async function createJJ(options) {
         const current = await graph.getChange(changeId);
         if (current) redoChangeSnapshot[changeId] = current;
       }
+      // Capture disk state right before this undo() runs. Used both as
+      // `redoFileSnapshot` (for a later redo() — only meaningful when this
+      // reversal actually touches files) AND, unconditionally, as THIS
+      // undo operation's own `view.fileSnapshot` "before" value below —
+      // see issue #43(1): undo()/redo()/operations.restore() used to
+      // record `view: landingView` verbatim, i.e. reusing the LANDING
+      // operation's own recorded fileSnapshot (disk state before THAT op
+      // ran) instead of disk state before THIS undo ran. A later
+      // restore()/undo() scanning forward past this one would then pick
+      // up that stale, wrong snapshot instead of what was actually on disk
+      // right before this undo executed.
+      const diskSnapshotBeforeThisOp = await snapshotFilesystem();
       const redoFileSnapshot =
-        reversal.fileSnapshot !== undefined ? await snapshotFilesystem() : undefined;
+        reversal.fileSnapshot !== undefined ? diskSnapshotBeforeThisOp : undefined;
       let redoConflictsSnapshot;
       if (reversal.conflictsSnapshot !== undefined) {
         await conflicts.load();
@@ -10223,7 +10411,7 @@ async function createJJ(options) {
         redoFileSnapshot,
         redoConflictsSnapshot,
         parents: [],
-        view: landingView,
+        view: { ...landingView, fileSnapshot: diskSnapshotBeforeThisOp },
       });
 
       const restoredFileCount =
@@ -10317,6 +10505,15 @@ async function createJJ(options) {
           await baseGraph.updateChange(snapshot);
         }
       }
+
+      // Capture disk state right before THIS redo() mutates it — see issue
+      // #43(1)/the matching fix in undo(): `view: redoneView` below reuses
+      // the ORIGINAL (re-applied) operation's own recorded pointers, but
+      // its `fileSnapshot` sub-field must reflect disk state before THIS
+      // redo ran, not before that original operation ran, or a later
+      // restore()/undo() scanning forward past this redo would pick up a
+      // stale, wrong snapshot.
+      const diskSnapshotBeforeThisOp = await snapshotFilesystem();
       if (undoOp.redoFileSnapshot !== undefined) {
         await syncWorkingCopyFiles(undoOp.redoFileSnapshot);
       }
@@ -10337,7 +10534,7 @@ async function createJJ(options) {
         redoOf: undoOp.id,
         changeSnapshot: undoChangeSnapshot,
         parents: [],
-        view: redoneView,
+        view: { ...redoneView, fileSnapshot: diskSnapshotBeforeThisOp },
       });
 
       const restoredFileCount =
@@ -10643,6 +10840,17 @@ async function createJJ(options) {
           if (current) changeSnapshot[changeId] = current;
         }
 
+        // Capture disk state right before THIS restore() mutates it — see
+        // issue #43(1)/the matching fix in undo()/redo(): recording
+        // `view: targetOp.view` verbatim reused targetOp's OWN recorded
+        // `fileSnapshot` (disk state before targetOp ran), not disk state
+        // before THIS restore ran. A later restore()/undo() scanning
+        // forward past this one would then pick up that stale, wrong
+        // snapshot instead of what was actually on disk right before this
+        // restore executed — this is exactly the "forward restore to
+        // 'edit tip' lost style.css" repro.
+        const diskSnapshotBeforeThisOp = await snapshotFilesystem();
+
         await applyGraphReversal(reversal);
 
         // Record this restoration as a new operation
@@ -10652,7 +10860,7 @@ async function createJJ(options) {
           description: `restore to operation ${args.operation}`,
           parents: [],
           changeSnapshot,
-          view: targetOp.view,
+          view: { ...targetOp.view, fileSnapshot: diskSnapshotBeforeThisOp },
         });
 
         return {
@@ -10888,6 +11096,15 @@ async function createJJ(options) {
       await workingCopy.load();
       await userConfig.load();
 
+      // Capture disk state right before this squash mutates anything, so
+      // undo()/redo()/operations.restore() can rewind past it — see issue
+      // #43(1): squash() previously recorded no "files before" snapshot at
+      // all, so restoring to a point right before a squash ran had no
+      // recorded on-disk state and would fall through to whatever a LATER
+      // operation happened to record instead (the repro: a forward
+      // restore to "edit tip" lost `style.css`).
+      const fileSnapshotBefore = await snapshotFilesystem();
+
       // Support 'into' as alias for 'dest' (matches JJ CLI)
       const dest = args.into || args.dest;
 
@@ -11019,6 +11236,18 @@ async function createJJ(options) {
           // every on-disk file as untracked/new until something re-wrote
           // it and triggered a fresh auto-snapshot.
           fileSnapshot: { ...destChange.fileSnapshot },
+          // Marks this as an internal, synthetic artifact rather than
+          // something the user actually created — issue #43(2): if this
+          // squash is later undone, this change becomes unreferenced, and
+          // by then `destChange` may have been reverted to pre-squash
+          // content, making this change look "non-empty" relative to its
+          // (now-reverted) parent even though it never held any real user
+          // content of its own. The revset engine's orphan-visibility
+          // filter (_computeHiddenOrphans) treats `autoCreated` as
+          // sufficient on its own (given it's also unreferenced and
+          // undescribed) rather than re-diffing against a parent that may
+          // no longer resemble what this change was actually created from.
+          autoCreated: true,
         };
 
         await graph.addChange(newChange); // Middleware will sync to Git
@@ -11041,8 +11270,18 @@ async function createJJ(options) {
         view: {
           bookmarks: {},
           remoteBookmarks: {},
-          heads: [destChangeId],
+          // issue #43(1): this used to hard-code `[destChangeId]` — wrong
+          // whenever squash() created a fresh working-copy change on top
+          // of dest (the real new tip was `newWorkingCopyId`, not
+          // `destChangeId` itself), and incomplete whenever a sibling head
+          // elsewhere in the graph existed and wasn't touched by this
+          // squash at all ("two sibling changes report only one head
+          // between them"). computeCurrentHeads() reflects the WHOLE
+          // repo's actual head set after this squash, not just the
+          // changeId(s) this call happened to touch.
+          heads: await computeCurrentHeads(),
           workingCopy: newWorkingCopyId,
+          fileSnapshot: fileSnapshotBefore,
         },
       });
 
@@ -11114,6 +11353,12 @@ async function createJJ(options) {
       // abandoning any OTHER change must leave @ exactly where it was.
       const wasWorkingCopy = changeId === workingCopy.getCurrentChangeId();
 
+      // Capture disk state right before this abandon mutates anything, so
+      // undo()/redo()/operations.restore() can rewind past it — see issue
+      // #43(1): abandon() previously recorded no "files before" snapshot
+      // at all.
+      const fileSnapshotBefore = await snapshotFilesystem();
+
       // Dispatch change:abandoning event (preventable)
       await dispatchEventAsync(jj, 'change:abandoning', {
         operation: 'abandon',
@@ -11148,8 +11393,16 @@ async function createJJ(options) {
         view: {
           bookmarks: {},
           remoteBookmarks: {},
-          heads: [],
+          // issue #43(1): this used to hard-code `[]`, dropping every live
+          // head from the recorded operation (including any untouched
+          // sibling branch — "two sibling changes report only one head
+          // between them"). computeCurrentHeads() reflects the actual
+          // repo-wide head set right after this abandon (and its
+          // reparenting) ran, before the compensating jj.new() below (if
+          // any) records its own separate operation.
+          heads: await computeCurrentHeads(),
           workingCopy: workingCopy.getCurrentChangeId(),
+          fileSnapshot: fileSnapshotBefore,
         },
       });
 
@@ -13411,6 +13664,32 @@ async function createJJ(options) {
           throw new JJError('CONFLICT_NOT_FOUND', `Conflict ${args.conflictId} not found`);
         }
 
+        // Snapshot BEFORE mutating so undo()/redo()/operations.restore()
+        // can reverse this resolution — issue #43(4): conflicts.resolve()
+        // previously recorded no operation at all, so resolving a conflict
+        // could never be undone: no changeSnapshot of the working-copy
+        // change's content, no conflictsSnapshot of the pre-resolve
+        // conflict state, and no fileSnapshot of the on-disk content
+        // before the resolved content was written.
+        await graph.load();
+        await workingCopy.load();
+        // structuredClone matters here (unlike the read-only conflictsSnapshot
+        // capture in moveChange()/merge()): resolveConflict() below mutates
+        // the SAME conflict object in place (`conflict.resolved = true`),
+        // and Object.fromEntries() on the live Map would otherwise leave
+        // this "before" snapshot holding a reference to that very object —
+        // corrupting it into already showing `resolved: true` by the time
+        // it's recorded.
+        const conflictsSnapshotBefore = structuredClone({
+          conflicts: Object.fromEntries(conflicts.conflicts),
+          fileConflicts: Object.fromEntries(conflicts.fileConflicts),
+        });
+        const fileSnapshotBefore = await snapshotFilesystem();
+        const wcId = workingCopy.getCurrentChangeId();
+        const wcChange = await graph.getChange(wcId);
+        /** @type {Record<string, any>} */
+        const changeSnapshot = wcChange ? { [wcId]: structuredClone(wcChange) } : {};
+
         let resolvedContent;
 
         // v0.5: Support different resolution methods
@@ -13454,6 +13733,36 @@ async function createJJ(options) {
         await conflicts.resolveConflict(args.conflictId, 'manual');
         await conflicts.save();
 
+        // Refresh the working-copy change's own fileSnapshot to match the
+        // resolved on-disk content (conflicted files always live under
+        // the checked-out working copy — see the writeFile above), so
+        // undo()/restore() has an accurate "after" state to compare
+        // against, and log()/read() see the resolution immediately rather
+        // than waiting for the next auto-snapshot.
+        if (wcChange) {
+          wcChange.fileSnapshot = {
+            ...(wcChange.fileSnapshot || {}),
+            [conflict.path]: resolvedContent,
+          };
+          await graph.updateChange(wcChange);
+        }
+
+        await oplog.recordOperation({
+          timestamp: new Date().toISOString(),
+          user: await getUserOplogInfo(),
+          description: `resolve conflict ${args.conflictId} (${conflict.path})`,
+          parents: [],
+          changeSnapshot,
+          conflictsSnapshot: conflictsSnapshotBefore,
+          view: {
+            bookmarks: {},
+            remoteBookmarks: {},
+            heads: await computeCurrentHeads(),
+            workingCopy: wcId,
+            fileSnapshot: fileSnapshotBefore,
+          },
+        });
+
         return { resolved: true };
       },