isomorphic-jj 1.9.0 → 1.9.2

package/CHANGELOG.md

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

package/dist/index.cjs

@@ -991,6 +991,44 @@ class ChangeGraph {
  */
 
 
+/**
+ * Normalize an mtime value to a millisecond epoch number so two stat()
+ * results (or a stat() result and a stored value) can be compared by VALUE
+ * instead of by object identity (see issue #41).
+ *
+ * `fs.promises.stat()` returns a fresh `Date` instance on every call, so two
+ * separate stats of the same unchanged file are never `===`/`!==`-equal even
+ * when the underlying timestamp is identical. Additionally, once a tracked
+ * mtime has been through a `JSON.stringify`/`JSON.parse` round-trip (Storage
+ * persists working-copy state as JSON), a `Date` becomes an ISO string, not a
+ * `Date` — so the stored side of the comparison may be a `Date`, a plain
+ * epoch-ms number (this module now stores numbers going forward), or an ISO
+ * string (older/reloaded-from-disk state). This normalizes all three to a
+ * comparable number.
+ *
+ * Deliberately duck-types the Date case (`typeof value.getTime ===
+ * 'function'`) instead of `value instanceof Date`: Node's built-in `fs`
+ * module constructs `Stats.mtime` using its own realm's `Date`, which is not
+ * always the same `Date` constructor as this module's under test runners
+ * that sandbox each test file in its own VM context (observed under Jest
+ * with `--experimental-vm-modules`) — there, a real `Date` instance from
+ * `fs.promises.stat()` fails `instanceof Date` here even though it's a
+ * genuine Date. Duck-typing survives that realm mismatch.
+ *
+ * @param {Date|number|string|undefined} value
+ * @returns {number}
+ */
+function mtimeMs(value) {
+  if (value === null || value === undefined) return NaN;
+  if (typeof value === 'number') return value;
+  if (typeof value === 'string') return new Date(value).getTime();
+  // Per the type contract above, anything left is Date-like -- duck-typed
+  // (see the comment above) rather than `instanceof Date`, so no runtime
+  // check is needed here either; a value outside this contract is a caller
+  // bug, not something to silently coerce.
+  return /** @type {any} */ (value).getTime();
+}
+
 class WorkingCopy {
   /**
    * @param {Storage} storage - Storage manager instance
@@ -1162,8 +1200,10 @@ class WorkingCopy {
       try {
         const stats = await this.fs.promises.stat(fullPath);
 
-        // Fast path: check mtime and size
-        if (stats.mtime !== tracked.mtime || stats.size !== tracked.size) {
+        // Fast path: check mtime and size. Compare by VALUE (see mtimeMs
+        // above) — comparing the raw stat()/stored values with !== is
+        // always "different" even when nothing changed (issue #41).
+        if (mtimeMs(stats.mtime) !== mtimeMs(tracked.mtime) || stats.size !== tracked.size) {
           modified.push(path);
         }
       } catch (error) {
@@ -1274,12 +1314,19 @@ class WorkingCopy {
       }
 
       const prev = this.state.fileStates[rel];
-      const next = { mtime: stats.mtime, size: stats.size, mode: stats.mode };
+      // Store mtime as a plain epoch-ms number (not the raw stat() value):
+      // numbers round-trip through JSON exactly, so state reloaded from disk
+      // later compares identically to state still cached in-memory. Goes
+      // through mtimeMs() rather than assuming `.getTime()` exists directly —
+      // some fs implementations (e.g. the in-memory mock used in tests)
+      // return mtime as a plain epoch-ms number already, not a Date (see
+      // mtimeMs above and issue #41).
+      const next = { mtime: mtimeMs(stats.mtime), size: stats.size, mode: stats.mode };
 
       if (!prev) {
         this.state.fileStates[rel] = next;
         added.push(rel);
-      } else if (prev.mtime !== stats.mtime || prev.size !== stats.size) {
+      } else if (mtimeMs(stats.mtime) !== mtimeMs(prev.mtime) || prev.size !== stats.size) {
         this.state.fileStates[rel] = next;
         modified.push(rel);
       }
@@ -2668,9 +2715,12 @@ class RevsetEngine {
     const unquote = (/** @type {string} */ s) => s.trim().replace(/^['"]|['"]$/g, '');
 
     switch (name) {
-      case 'all':
+      case 'all': {
         await this.graph.load();
-        return this.graph.getAll().map((c) => c.changeId);
+        const allChanges = this.graph.getAll();
+        const hidden = await this._computeHiddenOrphans(allChanges);
+        return allChanges.filter((c) => !hidden.has(c.changeId)).map((c) => c.changeId);
+      }
 
       // `builtin_log()` (jj v0.44) is the revset the built-in `jj log` uses
       // when no user override is configured. isomorphic-jj's `log()` already
@@ -2678,9 +2728,12 @@ class RevsetEngine {
       // `builtin_log()` is a pure alias for that same default — this lets
       // callers compose it (e.g. `builtin_log() & mine()`) instead of
       // duplicating `all()`.
-      case 'builtin_log':
+      case 'builtin_log': {
         await this.graph.load();
-        return this.graph.getAll().map((c) => c.changeId);
+        const allChanges = this.graph.getAll();
+        const hidden = await this._computeHiddenOrphans(allChanges);
+        return allChanges.filter((c) => !hidden.has(c.changeId)).map((c) => c.changeId);
+      }
 
       case 'none':
         return [];
@@ -3141,6 +3194,108 @@ class RevsetEngine {
     return ancestors;
   }
 
+  /**
+   * Change IDs that `all()`/`builtin_log()` (and therefore the default
+   * `jj.log()`) should exclude — issue #37(b).
+   *
+   * undo()/redo()/operations.restore() deliberately don't delete a change
+   * record for a `new()`/`squash()` that gets reverted — they only un-ref
+   * it (restore the working-copy pointer/heads that made it reachable),
+   * matching real jj where an unreachable change stays resolvable by its
+   * change id (hidden, not gone) until explicitly gc'd — see
+   * computeGraphReversal's doc comment in repository.js. But that means
+   * the orphaned change record lingers in the graph, and before this fix
+   * `all()` (a flat `graph.getAll()`) surfaced it in `log()` right
+   * alongside everything still actually reachable.
+   *
+   * Real jj hides a commit from the default log when it is BOTH:
+   *   - unreachable from any visible head (not itself a head, and not an
+   *     ancestor of one), AND
+   *   - "discardable": empty (no file diff versus its own parent) and
+   *     undescribed.
+   * Merge commits (2+ parents) are conservatively never treated as
+   * "empty" here — real jj's diff-emptiness rule for merges is more
+   * involved and isn't needed by anything this package creates today.
+   *
+   * "Visible head" here deliberately does NOT mean "any change with no
+   * children" (that's what the `visible_heads()` revset function computes,
+   * structurally, from the raw graph) — an orphan `new()`/`squash()`
+   * change that undo() un-referenced has no children EITHER, so it would
+   * trivially count as its own head under that definition and never be
+   * excludable. Real jj instead tracks an explicit, maintained set of
+   * heads in its View (updated as operations run — abandoning/squashing a
+   * change removes it, rebasing children onto a new parent removes the
+   * old parent, etc.). This package doesn't thread the operation log's
+   * `view.heads` through to the revset engine, but the working-copy
+   * pointer plus every bookmark/tag target is the closest available
+   * proxy for "what's actually still in play" — anything only reachable
+   * from those, not from every dangling graph leaf.
+   *
+   * @param {any[]} allChanges - `graph.getAll()`
+   * @returns {Promise<Set<string>>} change IDs to exclude
+   */
+  async _computeHiddenOrphans(allChanges) {
+    const trackedHeads = new Set();
+    try {
+      const wcId = this.workingCopy && this.workingCopy.getCurrentChangeId();
+      if (wcId) trackedHeads.add(wcId);
+    } catch {
+      // working copy not loaded/available — fine, just no wc-based root.
+    }
+    if (this.bookmarkStore) {
+      await this.bookmarkStore.load();
+      for (const bookmark of await this.bookmarkStore.list()) {
+        if (bookmark && bookmark.changeId) trackedHeads.add(bookmark.changeId);
+      }
+    }
+    if (this.tagStore) {
+      for (const tag of await this.tagStore.list()) {
+        if (tag && tag.changeId) trackedHeads.add(tag.changeId);
+      }
+    }
+
+    const reachable = new Set();
+    for (const headId of trackedHeads) {
+      for (const id of await this.getAncestors(headId)) {
+        reachable.add(id);
+      }
+    }
+
+    // Sentinel "no message given" descriptions this package itself writes
+    // (new()'s '(no description)', squash()'s post-squash working-copy
+    // change '(no description set)') are, for visibility purposes, just
+    // as undescribed as a genuinely empty/missing description field.
+    const UNDESCRIBED = new Set([undefined, null, '', '(no description)', '(no description set)']);
+
+    const byId = new Map(allChanges.map((c) => [c.changeId, c]));
+    const isEmpty = (/** @type {any} */ change) => {
+      const parents = change.parents || [];
+      if (parents.length === 0) {
+        return !change.fileSnapshot || Object.keys(change.fileSnapshot).length === 0;
+      }
+      if (parents.length > 1) return false; // merges: not handled by this rule
+      const parent = byId.get(parents[0]);
+      const parentSnapshot = (parent && parent.fileSnapshot) || {};
+      const ownSnapshot = change.fileSnapshot || {};
+      const parentKeys = Object.keys(parentSnapshot);
+      const ownKeys = Object.keys(ownSnapshot);
+      if (parentKeys.length !== ownKeys.length) return false;
+      return parentKeys.every((k) => parentSnapshot[k] === ownSnapshot[k]);
+    };
+
+    const hidden = new Set();
+    for (const change of allChanges) {
+      if (
+        !reachable.has(change.changeId) &&
+        isEmpty(change) &&
+        UNDESCRIBED.has(change.description)
+      ) {
+        hidden.add(change.changeId);
+      }
+    }
+    return hidden;
+  }
+
   /**
    * Resolve a revset argument to a set of change IDs (v1.5).
    *
@@ -7899,7 +8054,16 @@ async function createJJ(options) {
     await graph.load();
     for (const [changeId, snapshot] of Object.entries(reversal.changeSnapshotToApply)) {
       if (await graph.getChange(changeId)) {
-        await graph.updateChange(snapshot);
+        // Bypass the git-sync middleware (baseGraph, not the wrapped
+        // `graph`): undo/restore are pure reverts, and `snapshot` already
+        // carries the change's ORIGINAL commitId from before the reverted
+        // operation(s) ran. Going through graph.updateChange() would fire
+        // onUpdateChange -> syncChangeToGit(), which mints a brand-new
+        // commit (and thus a new commitId) from the CURRENT tree instead
+        // of restoring the one that was actually there — see issue #37(c):
+        // "undo/restore give reverted commits new commit IDs". Writing the
+        // snapshot verbatim via baseGraph puts the original commitId back.
+        await baseGraph.updateChange(snapshot);
       }
     }
 
@@ -10037,6 +10201,16 @@ async function createJJ(options) {
       // which operation it targeted so a following undo() can walk one
       // step further back (resolveUndoTarget) instead of toggling, and
       // carrying exactly what redo() needs to re-apply (captured above).
+      //
+      // Also record `changeSnapshot: redoChangeSnapshot` — the SAME
+      // ground-truth-before-this-op values, but under the field name
+      // computeGraphReversal() actually scans for. Without this, undo()
+      // itself was the one mutating operation in the whole API that never
+      // recorded its own changeSnapshot, so a LATER undo() targeting THIS
+      // undo (to step back past it) had nothing to restore: it would
+      // repoint the working copy and files, but leave whatever this
+      // undo() overwrote (e.g. a change's description) exactly as this
+      // undo() left it. See issue #37(a).
       await oplog.recordOperation({
         timestamp: new Date().toISOString(),
         user: await getUserOplogInfo(),
@@ -10044,6 +10218,7 @@ async function createJJ(options) {
         eventType: 'undo',
         targetOpId: targetOp.id,
         undoneOpId: targetOp.id, // kept for API/type compatibility
+        changeSnapshot: redoChangeSnapshot,
         redoChangeSnapshot,
         redoFileSnapshot,
         redoConflictsSnapshot,
@@ -10121,9 +10296,25 @@ async function createJJ(options) {
       // by scanning forward. undo() captured it directly for exactly this
       // reason (see its own comment).
       await graph.load();
+
+      // Capture ground truth right before overwriting, same as undo()
+      // does for its own changeSnapshot (issue #37a) — lets a later
+      // undo() targeting THIS redo op restore what redo() is about to
+      // clobber, instead of finding no changeSnapshot at all.
+      /** @type {Record<string, any>} */
+      const undoChangeSnapshot = {};
+      for (const changeId of Object.keys(undoOp.redoChangeSnapshot || {})) {
+        const current = await graph.getChange(changeId);
+        if (current) undoChangeSnapshot[changeId] = current;
+      }
+
       for (const [changeId, snapshot] of Object.entries(undoOp.redoChangeSnapshot || {})) {
         if (await graph.getChange(changeId)) {
-          await graph.updateChange(snapshot);
+          // Bypass the git-sync middleware — see the matching comment in
+          // applyGraphReversal(). `snapshot` already carries the change's
+          // correct commitId from before the undo it's reversing ran
+          // (issue #37c applies to redo() too).
+          await baseGraph.updateChange(snapshot);
         }
       }
       if (undoOp.redoFileSnapshot !== undefined) {
@@ -10144,6 +10335,7 @@ async function createJJ(options) {
         description: 'redo operation',
         eventType: 'redo',
         redoOf: undoOp.id,
+        changeSnapshot: undoChangeSnapshot,
         parents: [],
         view: redoneView,
       });
@@ -10434,6 +10626,23 @@ async function createJJ(options) {
         // Revert the change graph, working-copy files, and conflict state
         // to exactly what they were right after targetOp ran.
         const reversal = computeGraphReversal(ops, targetOp);
+
+        // Capture ground truth for every changeId this restore is about to
+        // overwrite, BEFORE applying the reversal — exactly like undo()
+        // does for its own changeSnapshot. Without this, restore()'s own
+        // oplog entry carried no changeSnapshot at all, so undoing the
+        // restore itself had nothing to put back: a later undo() would
+        // repoint the working copy and files, but leave whatever the
+        // restore had just overwritten (e.g. a change's description)
+        // exactly as the restore left it. See issue #37(a).
+        await graph.load();
+        /** @type {Record<string, any>} */
+        const changeSnapshot = {};
+        for (const changeId of Object.keys(reversal.changeSnapshotToApply)) {
+          const current = await graph.getChange(changeId);
+          if (current) changeSnapshot[changeId] = current;
+        }
+
         await applyGraphReversal(reversal);
 
         // Record this restoration as a new operation
@@ -10442,6 +10651,7 @@ async function createJJ(options) {
           user: await getUserOplogInfo(),
           description: `restore to operation ${args.operation}`,
           parents: [],
+          changeSnapshot,
           view: targetOp.view,
         });
 
@@ -10801,10 +11011,22 @@ async function createJJ(options) {
           },
           description: '(no description set)',
           timestamp: new Date().toISOString(),
-          fileSnapshot: {},
+          // Start from the DESTINATION's tree (which now includes source's
+          // folded-in changes, set above), not an empty object — matches
+          // real `jj squash`, where the new working-copy change looks
+          // identical to its new parent until you touch something. Issue
+          // #39: this used to hard-code `{}`, so status()/snapshot() saw
+          // every on-disk file as untracked/new until something re-wrote
+          // it and triggered a fresh auto-snapshot.
+          fileSnapshot: { ...destChange.fileSnapshot },
         };
 
         await graph.addChange(newChange); // Middleware will sync to Git
+        // Sync the working directory to match (issue #30's fix for
+        // new()/edit(); squash()'s own synthetic post-squash change never
+        // did this) — a no-op when source's parent was already dest (the
+        // common case), but necessary whenever source/dest aren't adjacent.
+        await syncWorkingCopyFiles(newChange.fileSnapshot);
         await workingCopy.setCurrentChange(newChangeId);
         newWorkingCopyId = newChangeId;
       }
@@ -10886,6 +11108,12 @@ async function createJJ(options) {
         throw new JJError('CHANGE_NOT_FOUND', `Change ${changeId} not found`);
       }
 
+      // Captured BEFORE anything mutates — see issue #38: abandoning the
+      // change @ currently points at must move @ off it (real jj checks
+      // out a fresh empty change on the abandoned change's own parent(s));
+      // abandoning any OTHER change must leave @ exactly where it was.
+      const wasWorkingCopy = changeId === workingCopy.getCurrentChangeId();
+
       // Dispatch change:abandoning event (preventable)
       await dispatchEventAsync(jj, 'change:abandoning', {
         operation: 'abandon',
@@ -10938,6 +11166,17 @@ async function createJJ(options) {
         { cancelable: false }
       );
 
+      // If @ was pointing at the change we just abandoned, it can't stay
+      // there — real jj moves @ to a new empty change on the abandoned
+      // change's own parent(s) (issue #38). Reuse new()'s own "create an
+      // empty change with given parents" logic rather than duplicating it
+      // — this is exactly the workaround callers had to reach for
+      // themselves (`new({ parents: [parentOfAt] })` before abandoning).
+      if (wasWorkingCopy) {
+        const newWorkingCopyChange = await jj.new({ parents: change.parents || [] });
+        return { ...change, newWorkingCopyChangeId: newWorkingCopyChange.changeId };
+      }
+
       return change;
     },