isomorphic-jj 1.10.0 → 1.11.0

package/CHANGELOG.md

@@ -1,5 +1,118 @@
 # Changelog
 
+## 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):

package/dist/index.cjs

@@ -8268,8 +8268,26 @@ async function createJJ(options) {
         const wcId = workingCopy.getCurrentChangeId();
         const change = await graph.getChange(wcId);
         if (change) {
+          const oldFileSnapshot = change.fileSnapshot ? structuredClone(change.fileSnapshot) : {};
           change.fileSnapshot = await snapshotFilesystem();
           await graph.updateChange(change);
+
+          // Issue #45: if the working-copy change isn't a leaf (e.g. we
+          // edit()'d into an older change earlier in the session), its
+          // descendants' fileSnapshot still reflects the OLD content and
+          // needs to be rebased onto the content just committed above —
+          // matching real jj's automatic rebase-on-edit. edit() itself is a
+          // pure checkout and never mutates content, so this is the actual
+          // moment content changes and the right place to propagate. `jj`
+          // (not `this`) is used here because this function is a plain
+          // closure, not a method of the `jj` object — but `jj` is a const
+          // in the same enclosing scope and this function only ever runs
+          // after `jj` is fully constructed, so the self-reference is safe
+          // (same pattern used elsewhere in this file, e.g. `jj.new(...)`).
+          const descendants = await jj._findDescendants(wcId, null);
+          if (descendants.length > 0) {
+            await jj._rebuildDescendants(wcId, null, oldFileSnapshot);
+          }
         }
       } catch {
         // Best-effort content refresh; tracking state is already updated.
@@ -9874,9 +9892,21 @@ async function createJJ(options) {
           changeSnapshot[wcId] = structuredClone(change);
           change.fileSnapshot = currentDiskSnapshot;
           await graph.updateChange(change);
+
+          // Issue #45: if the working-copy change isn't a leaf (e.g. we
+          // edit()'d into an older change earlier in the session), its
+          // descendants' fileSnapshot still reflects the OLD content and
+          // needs to be rebased onto the content just committed above —
+          // matching real jj's automatic rebase-on-edit. edit() itself is a
+          // pure checkout and never mutates content, so this is the actual
+          // moment content changes and the right place to propagate.
+          const descendants = await this._findDescendants(wcId, null);
+          if (descendants.length > 0) {
+            await this._rebuildDescendants(wcId, null, changeSnapshot[wcId].fileSnapshot);
+          }
         }
       } catch {
-        // Best-effort content refresh.
+        // Best-effort content refresh (including descendant propagation).
       }
 
       await oplog.recordOperation({
@@ -10227,6 +10257,22 @@ async function createJJ(options) {
             changeSnapshot[previousChangeId] = structuredClone(previousChange);
             previousChange.fileSnapshot = currentSnapshot;
             await graph.updateChange(previousChange);
+
+            // Issue #45: this is the OTHER place a checked-out change's
+            // content gets committed to the graph — not through snapshot()/
+            // autoSnapshotWorkingCopy() at all, but here, inline, when
+            // edit() leaves a change it was checked out on. If that change
+            // isn't a leaf (we'd edit()'d into an ancestor), its descendants
+            // still have the OLD content and need the same rebase-on-edit
+            // treatment applied at the other two commit sites.
+            const descendants = await this._findDescendants(previousChangeId, null);
+            if (descendants.length > 0) {
+              await this._rebuildDescendants(
+                previousChangeId,
+                null,
+                changeSnapshot[previousChangeId].fileSnapshot
+              );
+            }
           }
         }
       }
@@ -12465,9 +12511,27 @@ async function createJJ(options) {
      * @private
      * @param {string} ancestorId - The ancestor change that was updated
      * @param {string} stopAtChangeId - Don't rebuild this change (usually working copy)
-     * @deprecated Use _rebuildDescendantsWithStates instead
+     * @param {Record<string, string>} [originalAncestorSnapshot] - The
+     *   ancestor's fileSnapshot as it was BEFORE the caller's own
+     *   `graph.updateChange()` for `ancestorId` ran. Callers must invoke this
+     *   function AFTER committing the ancestor's new content (that's the
+     *   natural order — the ancestor's content must exist before its
+     *   descendants can be rebased onto it), but that means a live
+     *   `graph.getChange(ancestorId).fileSnapshot` read inside this function
+     *   would already see the NEW content. For the ancestor's DIRECT
+     *   children, this function compares each descendant's stale content
+     *   against "the original parent state" to figure out which lines are
+     *   the descendant's own edits; if that "original" state were actually
+     *   the already-new ancestor content, every line of the stale
+     *   descendant would look like a deliberate edit (stale != new) and get
+     *   preserved verbatim — silently reproducing the staleness instead of
+     *   fixing it. Passing the pre-mutation snapshot here lets the ancestor's
+     *   direct children be diffed against the correct baseline. Deeper
+     *   descendants are unaffected (their own immediate parent hasn't been
+     *   mutated yet when this function reads it, so the live read is
+     *   correct for them). Optional for backward compatibility.
      */
-    async _rebuildDescendants(ancestorId, stopAtChangeId) {
+    async _rebuildDescendants(ancestorId, stopAtChangeId, originalAncestorSnapshot) {
       // Find all descendants of ancestorId
       const allChanges = graph.getAll();
 
@@ -12475,11 +12539,16 @@ async function createJJ(options) {
       const originalParentStates = new Map();
       for (const change of allChanges) {
         if (change.parents && change.parents.length > 0) {
-          const parent = await graph.getChange(change.parents[0]);
+          const parentId = change.parents[0];
+          const parent = await graph.getChange(parentId);
           if (parent) {
+            const parentSnapshot =
+              parentId === ancestorId && originalAncestorSnapshot !== undefined
+                ? JSON.parse(JSON.stringify(originalAncestorSnapshot))
+                : JSON.parse(JSON.stringify(parent.fileSnapshot || {}));
             originalParentStates.set(change.changeId, {
-              parentId: change.parents[0],
-              parentSnapshot: JSON.parse(JSON.stringify(parent.fileSnapshot || {})),
+              parentId,
+              parentSnapshot,
             });
           }
         }
@@ -12549,30 +12618,78 @@ async function createJJ(options) {
         const allFiles = new Set([
           ...Object.keys(descendant.fileSnapshot || {}),
           ...Object.keys(parent.fileSnapshot || {}),
+          ...Object.keys(originalParentSnapshot || {}),
         ]);
 
         for (const filePath of allFiles) {
+          const descendantExists = Object.prototype.hasOwnProperty.call(
+            descendant.fileSnapshot || {},
+            filePath
+          );
+          const originalParentExists = Object.prototype.hasOwnProperty.call(
+            originalParentSnapshot || {},
+            filePath
+          );
+          const updatedParentExists = Object.prototype.hasOwnProperty.call(
+            parent.fileSnapshot || {},
+            filePath
+          );
+
+          // A file's EXISTENCE is a separate question from its content —
+          // coercing "doesn't exist" to '' before diffing (the previous
+          // version of this loop did) means a descendant that deliberately
+          // deleted a file the old parent had gets that file resurrected as
+          // an empty string once rebuilt, instead of staying deleted. This
+          // was a real, latent bug: nothing called this function at all
+          // until issue #45 gave it a real caller, so it was never
+          // exercised against a deletion before.
+          if (
+            descendantExists === originalParentExists &&
+            (!descendantExists ||
+              descendant.fileSnapshot[filePath] === originalParentSnapshot[filePath])
+          ) {
+            // Descendant never touched this file relative to its old
+            // parent (same existence + content as before) -- just follow
+            // whatever the updated parent did with it (added, removed, or
+            // changed since the descendant branched off).
+            if (updatedParentExists) newSnapshot[filePath] = parent.fileSnapshot[filePath];
+            continue; // else: stays deleted -- don't add it to newSnapshot
+          }
+
+          if (originalParentExists && !descendantExists) {
+            // Descendant deliberately deleted a file the old parent had —
+            // preserve that deletion rather than resurrecting it.
+            continue;
+          }
+
+          if (!originalParentExists && descendantExists && !updatedParentExists) {
+            // Descendant added a file that didn't exist on either side of
+            // the parent at all -- keep the descendant's own addition.
+            newSnapshot[filePath] = descendant.fileSnapshot[filePath];
+            continue;
+          }
+
+          // Both the descendant and the parent have real content for this
+          // file (whether or not it existed originally) -- do the actual
+          // line-level replay: find which lines the descendant changed
+          // from the OLD parent, then reapply just those lines onto the
+          // NEW parent's content.
           const descendantContent = descendant.fileSnapshot[filePath] || '';
           const originalParentContent = originalParentSnapshot[filePath] || '';
           const updatedParentContent = parent.fileSnapshot[filePath] || '';
 
-          // Find which lines descendant modified from original parent
           const descendantLines = descendantContent.split('\n');
           const originalParentLines = originalParentContent.split('\n');
           const updatedParentLines = updatedParentContent.split('\n');
 
-          // Rebuild file: start with updated parent, apply descendant's modifications
           const resultLines = [...updatedParentLines];
 
-          // Find lines that descendant modified
           for (let i = 0; i < Math.max(descendantLines.length, originalParentLines.length); i++) {
             const descendantLine = i < descendantLines.length ? descendantLines[i] : undefined;
             const originalParentLine =
               i < originalParentLines.length ? originalParentLines[i] : undefined;
 
-            // If descendant modified this line from original parent, apply that modification
             if (descendantLine !== originalParentLine) {
-              // Extend resultLines if needed
               while (resultLines.length <= i) {
                 resultLines.push('');
               }