isomorphic-jj 1.9.2 → 1.11.0

package/CHANGELOG.md

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