isomorphic-jj 1.7.0 → 1.9.0

package/CHANGELOG.md

@@ -1,5 +1,427 @@
 # Changelog
 
+## 1.9.0 — merge the scoped and unscoped version lineages
+
+No code change — a deliberate, one-time exception to this family's usual
+"version restarts at 0.0.0 on a scope move" convention, forced by making
+the unscoped `isomorphic-jj` mirror permanent (see the unscoped-mirror
+workflow's own history) rather than a one-off "final release" bridge:
+`isomorphic-jj`'s unscoped name already had real published history through
+**1.8.0** from before the `@johnhenry/*` rename, while the scoped package
+had separately restarted at 0.0.0 and reached 0.4.0. Both names publish
+the same version on every release from here on, so the shared version has
+to sit above BOTH names' currently-published maximum, or the unscoped
+mirror's `npm install isomorphic-jj` would move npm's `latest` tag
+*backward* in version number the moment it published. `1.9.0` is one
+minor above the unscoped side's existing 1.8.0 ceiling — chosen over a
+patch bump because this release also carries real new functionality
+(0.3.0/0.4.0's `jj converge`, N-way divergence resolution, and the four
+other jj-v0.45 fixes), not just the version-numbering fix itself.
+
+Going forward, `publish.yml`/`publish-unscoped.yml` both preflight-check
+that the tag being published is strictly greater than whatever's
+currently live under EITHER name before publishing either one, so this
+can't silently regress again.
+
+## 0.4.0 — `converge()` resolves any number of divergent copies
+
+Follow-up to 0.3.0's `converge()` (#32): it originally capped automatic
+resolution at exactly two divergent copies, throwing `CONVERGE_AMBIGUOUS`
+for a third. That cap is gone — `converge()` now resolves any number of
+copies of one change id in a single call. Real jj's own CLI still only
+converges one *change id* per invocation as of v0.45.1 (an explicit TODO
+in its own source: "consider adding logic to deal with more than one
+divergent change-id in one invocation"), which is what this package's
+changeId-at-a-time API already matched — this follow-up instead closes
+the gap in what happens *within* that one change id, where real jj's
+underlying engine (`TruncatedEvolutionGraph`/`find_divergent_changes`)
+already resolves every divergent revision together, not just a pair.
+
+### Changed
+
+- **`converge()` is N-way, not pairwise.** The per-path resolution rule
+  generalizes directly: for each file, collect every DISTINCT value across
+  all copies that differs from the shared base. Zero distinct changed
+  values means nobody touched it; exactly one means only one side (or
+  several copies that happened to make the identical change) touched it,
+  and that value wins; two or more is a genuine conflict between that many
+  copies. `CONVERGE_AMBIGUOUS` no longer exists — there is nothing left for
+  it to guard against.
+- **A conflict with more than two disagreeing copies carries a new `sides`
+  shape.** Every other conflict in this codebase (from `merge()`/
+  `rebase()`) is inherently two-sided and keeps `sides: { base, left,
+  right }`. An N-way `converge()` conflict instead gets `sides: { base,
+  versions }`, where `versions` is `Array<{ commitId, content }>` — one
+  entry per distinct disagreeing value, so a caller can tell which
+  divergent copy contributed which content without decoding a fixed
+  left/right pair. Added `ConflictModel.createNWayConflict()` as the one
+  place that builds this shape.
+
+## 0.3.0 — Track jj through v0.45.1
+
+Five fixes/additions found via real usage of isomorphic-jj in a browser
+showcase app (ORRERY), spanning the browser entry, op-log/undo, and
+graph-rewrite (squash/rebase/abandon) machinery — grouped into one release
+because several of them touch the same shared machinery. Also closes the
+version gap to jj v0.45.1 (v0.45.0 added `jj converge`; v0.45.1 was
+patch-only, no JS-relevant changes).
+
+### Fixed
+
+- **The `/browser` entry can now actually run in a bundle (#28).**
+  `createBrowserFS()` called `require('@isomorphic-git/lightning-fs')`,
+  which doesn't exist in an ESM browser bundle; it's now an async
+  `import()`, and also accepts an injected `fs` (an instance, or a
+  LightningFS-shaped constructor) so callers can bring `memfs` or their
+  own. The four protobuf-backed stores (`JJCheckout`, `JJTreeState`,
+  `JJOperationStore`, `JJViewStore`) loaded their `.proto` schemas via
+  `protobuf.load()` against a `__dirname`-derived filesystem path, which
+  has no meaning in a bundle; they now build a `protobufjs` `Root` from
+  precompiled reflection JSON (`src/protos/*.json.js`, regenerated by
+  `npm run build:protos`, wired into `npm run build`) via the
+  dependency-free `protobufjs/light.js` entry point. Bundling a real
+  scratch app (`esbuild --platform=browser`) against the fix surfaced
+  several more Node-only assumptions that block a real browser run, fixed
+  the same way (isomorphic, not bundler-specific hacks): a bare
+  `import path from 'path'` (→ `src/utils/posix-path.js`, a tiny
+  POSIX-only join/dirname/resolve — this also fixes a latent Windows bug,
+  since Node's `path.join` uses backslashes there and git/jj paths must
+  never); `import crypto from 'crypto'` / dynamic `import('crypto')` (→
+  `randomHex()` in `id-generation.js`, built on the `crypto.getRandomValues`
+  global that file already used elsewhere); direct `Buffer.from`/
+  `Buffer.isBuffer` calls (→ `src/utils/bytes.js`, which only ever needs
+  `Uint8Array` and prefers a real `Buffer` when present so existing Node
+  behavior is unchanged); `fs.promises.mkdir(p, { recursive: true })`
+  (LightningFS silently ignores `recursive` and throws `ENOENT` on a
+  missing parent — `src/utils/mkdirp.js` walks and creates each segment
+  instead); and a few `readFile`/`writeFile` calls using the hyphenated
+  `'utf-8'` spelling (LightningFS only accepts the exact string `'utf8'`).
+  Verified end-to-end by bundling a scratch app and running it in real
+  headless Chromium: createBrowserFS → createJJ → git.init → write →
+  describe → log all completed successfully against IndexedDB-backed
+  LightningFS.
+- **`undo()`/`operations.restore()` now revert graph rewrites, and `undo()`
+  walks progressively further back instead of undoing itself (#29).**
+  `squash()`/`moveChange()` (rebase)/`abandon()` never recorded a
+  changeSnapshot, so undo() had nothing to restore their in-place
+  ChangeGraph mutations — the DAG stayed rewritten after "undoing" them.
+  They now do, the same mechanism issue #12 introduced for `describe()`.
+  Calling `undo()` twice also only undid the undo: since `undo()` is
+  itself recorded as a new operation, a second `undo()` naively targeting
+  the log's raw parent chain landed back on the just-undone operation
+  instead of stepping further into the past — contradicting real jj's
+  documented behavior (`jj-undo(1)`: "If jj undo is used repeatedly, it
+  will restore increasingly older operations"). A new `resolveUndoTarget()`
+  recognizes 'undo'/'redo' bookkeeping operations in the log and steps
+  past them. `operations.restore()` previously only touched bookmarks and
+  the working-copy pointer; it now shares the same
+  `computeGraphReversal()`/`applyGraphReversal()` primitive as `undo()`/
+  `redo()` to fully revert the graph, files, and conflict state to any
+  earlier operation. Also fixed in passing: `undo()` used to
+  unconditionally clear ALL conflicts whenever the operation being undone
+  hadn't recorded its own conflict snapshot (true for every op except
+  `merge()`) — undoing an unrelated `describe()` silently wiped conflicts
+  from an earlier, unrelated `merge()`.
+- **`squash()` merges file content, not just descriptions (#30).** It
+  combined the two descriptions into the destination but never moved the
+  source change's file contents into it — the squashed change's tree was
+  left completely unchanged. It now computes what source actually changed
+  relative to its own parent (added/modified/deleted paths) and folds just
+  that diff onto dest, rather than overwriting dest's whole snapshot with
+  source's.
+- **`abandon(changeId)` re-parents children (#30).** It set the abandoned
+  flag but left children pointing at the abandoned commit; it now
+  re-parents every child onto the abandoned change's own parent(s)
+  (matching real `jj abandon`), including making a child a root when the
+  abandoned change had no parent.
+- **`edit()`/`new()` fully sync the working copy (#30).** They wrote the
+  target change's files but only ever overlaid them on top of whatever was
+  already on disk, so a file present in the previously-checked-out change
+  but absent from the target leaked into the next snapshot. Both now go
+  through a shared `syncWorkingCopyFiles()` helper that deletes every
+  currently-tracked file NOT in the target snapshot in addition to writing
+  everything the target has. `new()` previously didn't touch the working
+  directory at all when targeting a change other than the current head's
+  default parent; it now checks the target out too.
+- **`rebase()` performs a real three-way merge and detects conflicts
+  (#31).** Rebasing a change onto a sibling that edited the same lines
+  kept the rebased change's file contents verbatim and recorded no
+  conflict. `moveChange()` (which `rebase()` delegates to) now runs the
+  same `detectConflicts()` three-way merge `merge()` already used, against
+  (old base = the change's own parent before reparenting, old commit = the
+  change's own content, new base = the new parent's content), recording
+  any detected conflict the same way `merge()` does.
+
+### Added
+
+- **`converge(changeId)` — auto-resolve divergent commits (#32, jj
+  v0.45.0).** A change is divergent when more than one visible commit
+  shares its change id; this package's `divergent()` revset already
+  modeled that (`c.divergent === true`, plus a changeId-occurrence count
+  across the graph), but nothing ever actually produced a divergent
+  change — the flag was set nowhere, and `ChangeGraph.nodes` being a
+  `Map<changeId, change>` made two entries genuinely sharing a changeId
+  structurally impossible via `addChange()`. `ChangeGraph.addDivergentCopy()`
+  is the actual producer: it stores a second commit under a synthetic
+  internal key while keeping its own `changeId` field equal to the
+  original's, which is what activates `divergent()` for real (previously
+  dead code) and gives `converge()` something to resolve.
+  `converge({ changeId })` (a bare changeId string also works) attempts
+  automatic resolution using the same three-way-merge/conflict-detection
+  machinery `rebase()` uses (#31) — reused, not duplicated a third time in
+  this codebase. On success, it creates one replacement commit (a fresh
+  commit id, the merged file content, combined description) under the same
+  change id and drops the superseded copy. On a genuine per-path conflict,
+  it's reported as data (`{ resolved: false, conflicts }`), matching
+  `merge()`'s own non-throwing convention for conflicts, and the conflict
+  is recorded the normal way. Throws `NOT_DIVERGENT` when there's nothing
+  to converge, and `CONVERGE_AMBIGUOUS` when more than two visible copies
+  exist — automatic resolution only attempts a pairwise merge, matching
+  real jj's non-interactive mode aborting resolution it can't disambiguate
+  rather than guessing.
+- **`ChangeGraph.deleteChange()`** — outright removal of a change record,
+  as distinct from `abandon()`'s soft-delete (`abandoned: true`) flag.
+  Added for undo()/redo()/operations.restore() to reverse an `addChange()`
+  when winding the graph back (#29), though in practice undo() never calls
+  it — see the doc comment on `computeGraphReversal()` for why a newly
+  created change is deliberately left in the graph (unreferenced, not
+  deleted) rather than torn down, matching real jj's "hidden, not gone"
+  model for unreachable commits.
+
+### Judgment calls worth flagging
+
+- **`write()`'s commit id/fileSnapshot staying stale until the next
+  snapshot is intentional, not a bug (#30).** jj has no staging area, but
+  real jj also doesn't recompute a tree/commit hash on every file write —
+  only when an actual `jj` command runs and snapshots the working copy.
+  `write()` is the equivalent of editing a file with your OS's own tools
+  outside of jj; `describe()`/`new()`/`edit()`/`status()`/etc. are the
+  equivalent of running a jj command. Documented rather than changed.
+- **Divergent copies are modeled as "another commit sharing a changeId",
+  not "two independent changeIds grouped together" (#32)** — matching what
+  the pre-existing (if previously non-functional) `divergent()` revset
+  already implied, rather than inventing a parallel representation.
+  Converge only handles the common case where the two copies share the
+  same parent(s) (a real divergence — two rewrites of one prior position
+  in history) and are leaves (no children of their own); this package's
+  graph model references parents by changeId, not by a more granular
+  commit-level pointer the way real jj's does, so a divergent copy's own
+  independent descendants aren't distinguishable from the primary copy's —
+  documented as a known limitation of the simplified graph model rather
+  than a full rewrite of how parent/child edges are stored.
+
+### Testing
+
+1823 tests passing (was 1732 at the start of this pass); lint (0 errors),
+format:check, typecheck, and build all still green. New test files:
+`tests/integration/undo-redo-graph-rewrites.test.js`,
+`tests/integration/squash-merge-abandon-reparent-file-sync.test.js`,
+`tests/integration/rebase-conflict-detection.test.js`,
+`tests/integration/converge.test.js`, plus new unit coverage for
+`src/utils/posix-path.js`, `src/utils/bytes.js`, `src/utils/mkdirp.js`,
+and `ChangeGraph`'s `deleteChange()`/`addDivergentCopy()`/
+`getDivergentSiblings()`/`deleteDivergentCopy()`.
+
+## 0.2.0 — 2026-09-02
+
+The first `@johnhenry/isomorphic-jj` release since 0.1.0, and the first
+scoped release to carry the audit fixes from PR #19 below — **the published
+0.1.0 tarball on npm predates #19** and does not include them.
+
+### Fixed (PR #19 — audit findings)
+
+Fixes all 8 findings from a bug-hunt audit of the storage/operation-log,
+undo/redo, revset, and Git-push layers:
+
+- **Same-process storage locking.** `Storage.appendLine()`/`write()` did
+  read-then-write with no lock, so concurrent same-process calls (e.g. a
+  user command racing `BackgroundOps`'s autosnapshot) could silently drop an
+  entry. Added a path-keyed in-process async mutex (`src/utils/mutex.js`)
+  that serializes the full critical section for both methods. Scoped to
+  same-process concurrency per the audit's guidance; cross-process locking
+  is a follow-up.
+- **`undo()` now reverts in-place content mutations.** Previously it never
+  restored `ChangeGraph`/tag mutations made in place. `describe()` now
+  snapshots the affected `ChangeGraph` node before mutating it (mirroring
+  the existing `fileSnapshot` pattern), and `undo()` restores it.
+  `operations.revert()` now also diffs/restores `tags`, not just
+  `bookmarks`.
+- **Ambiguous change-id prefixes now throw `AMBIGUOUS_ID`.** `show()`
+  previously resolved an ambiguous prefix silently to the first match; it
+  now throws `AMBIGUOUS_ID` listing all matches.
+- **`push()` surfaces categorized error codes.** Previously all per-ref
+  errors were swallowed into a bare ref name. Rejected refs now carry a
+  categorized `code` (`AUTH_FAILED`/`NETWORK_ERROR`/`NON_FAST_FORWARD`/
+  `OTHER`) and `reason` so callers can tell an auth failure apart from a
+  non-fast-forward rejection instead of guessing.
+- **Conflict-marker newline fix.** Markers could fuse content onto boundary
+  markers when content lacked a trailing newline; now forces a newline
+  separator for non-empty content.
+- **Atomic protobuf writes.** `jj-operation-store.js`, `jj-view-store.js`,
+  and `jj-tree-state.js` risked a truncated/undecodable file on a mid-write
+  crash. Now route through a shared `atomicWriteFile()` temp+rename helper
+  (`src/utils/atomic-write.js`).
+- **Weak temp-file naming fixed alongside storage locking** by adding a
+  random suffix, so two concurrent writes can't collide on the same temp
+  filename.
+- **Open-ended revset ranges** (`..b`, `a..`, `::`) failed with a
+  misleading "invalid IDs" error; they now delegate to the existing
+  `ancestors()`/`descendants()`/`all()` implementations.
+
+Closes #11–#18. See [PR #19](https://github.com/johnhenry/isomorphic-jj/pull/19).
+
+### CI (PR #20)
+
+- Dropped macOS from the test matrix — hosted macOS runners are scarce/slow
+  to schedule and this is a pure-JS library with no native code path; Linux
+  + Windows already cover realistic cross-platform risk. See
+  [PR #20](https://github.com/johnhenry/isomorphic-jj/pull/20).
+
+### Documentation overhaul: examples suite
+
+- **New `examples/` directory: 12 numbered, runnable examples** covering the
+  core loop (init/describe/new/log), stable-ID stacked changes, history
+  editing (split/squash/abandon/duplicate), branching and merging (including
+  `new({ parents })` for true merge changes), first-class conflicts, revsets,
+  bookmarks + tags (with the v0.44 `tag.track()` surface), Git interop,
+  configuration layers, undo/oplog/time travel, the `file.*` namespace, and
+  browser usage. Each example runs in a temp directory, cleans up after
+  itself, and *asserts* what it demonstrates, so the set doubles as a smoke
+  test. `npm run examples` runs the loop; `npm run example:NN` runs one.
+- **Example 08 exercises real `git.clone()`/`git.push()`/`git.fetch()` with
+  zero network**: it builds a bare fixture repo with the git CLI and serves
+  it on 127.0.0.1 through `git http-backend` (buffering request bodies so
+  CGI gets a `CONTENT_LENGTH` — isomorphic-git sends chunked bodies). Skips
+  cleanly where the git CLI is unavailable.
+- **CI**: the test workflow now runs the examples loop as a smoke step on
+  one matrix leg (ubuntu-latest / Node 22), deliberately a different leg
+  than the coverage gate.
+- Companion docs for the site (opensource.johnhenry.me) were written from
+  this repo's README/API/MIGRATION/CONFIGURATION material in the same pass;
+  behavioral quirks the examples surfaced (e.g. `file()` matching snapshots
+  rather than modifications, duration revsets needing committer timestamps,
+  `init()` after `git.clone()` re-rooting `refs/heads/main`) are documented
+  there rather than papered over.
+
+### Publishing
+
+- `@johnhenry/isomorphic-jj@0.2.0` is published from `main`. A final
+  unscoped bridge release, `isomorphic-jj@1.8.0` (same code as this
+  release), will follow so existing unscoped installs get one more version
+  pointing at the new package before the unscoped name is deprecated.
+
+## 0.1.0 — Track jj through v0.44
+
+Jujutsu shipped v0.44.0 (2026-08-05) since isomorphic-jj's last parity pass
+(v1.5.0/README, which tracked jj through v0.43). This release closes the gap
+for the parts of v0.43–v0.44 that are in scope for a headless, browser-safe
+reimplementation of jj's model — a library, not the `jj` CLI's terminal UX or
+its Rust process/Git-plumbing internals.
+
+### Added
+
+- **`tag.track({ name, remote })` / `tag.untrack({ name })`** — jj v0.44 made
+  tags remote-trackable the same way bookmarks already were, and added `jj
+  tag track`/`untrack` to manage that per-tag. `TagStore` now persists
+  tracking state (`{ remote, remoteName }` per local tag name) the same way
+  `BookmarkStore` already did for bookmarks, and `tag.list()` includes a
+  `tracking: { remote, ref }` field once a tag is tracked. The on-disk
+  `tags.json` format gained a `{ tags, tracked }` envelope; the old flat
+  `{ name: changeId }` format is still read for backward compatibility.
+- **`builtin_log()` revset function** — jj v0.44 added `builtin_log()` as an
+  alias for the revset the built-in `jj log` uses by default, so a custom
+  `revsets.log` config can extend it instead of duplicating it. isomorphic-jj's
+  `log()` has always defaulted to `all()` when no revset is given, so
+  `builtin_log()` is wired to the same set and can be composed like any other
+  revset function (`builtin_log() & mine()`).
+- **`file.search({ ..., nameOnly: true })`** — jj v0.44 changed `jj file
+  search`'s default CLI output to print every matched *line* (prefixed with
+  its file path), moving the old "just the file paths" behavior behind a new
+  `--name-only` flag. isomorphic-jj's `file.search()` already returned
+  structured per-line matches (`{ path, lineNumber, line }`) — that was
+  already the new default — so the only gap was the old, path-only shape;
+  `{ nameOnly: true }` now returns a deduplicated `string[]` of matching
+  paths, matching `--name-only`.
+
+### Changed
+
+- **`git_refs()` / `git_head()` revsets are now documented as deprecated.**
+  Upstream jj deprecated both in favor of `bookmarks()`/`tags()`/`@`, then
+  removed them outright in jj v0.43 (calling them in real jj now errors).
+  isomorphic-jj keeps them working — removing a function outright is a
+  breaking API change this pass didn't want to force on existing callers
+  unilaterally — but they're no longer listed in the revset engine's
+  "did you mean" suggestion text, and their JSDoc now calls out the upstream
+  removal and recommends `bookmarks()`/`tags()`/`@` instead. See "Not
+  changed" below for the case for a harder break in a future major version.
+
+### Testing
+
+1714 tests passing (was 1701); lint (0 errors), format:check, typecheck, and
+build all still green.
+
+### Not changed (needs a human design call)
+
+jj v0.43–v0.44 included several changes this pass deliberately left alone:
+
+- **`jj run`** (v0.43 new command, gained `--passthrough`/`--ignore-changes`/
+  `--ignore-errors`/oldest-first-ordering in v0.44) — runs an arbitrary
+  subprocess against each revision's own private working copy. isomorphic-jj
+  doesn't shell out to anything and has to keep working in browsers with no
+  process/filesystem access; "run a command" doesn't have an isomorphic
+  equivalent. Adding it would mean either a Node-only stub (inconsistent with
+  the rest of the API surface) or scope-creeping into a job-runner. Flagging
+  for a maintainer decision rather than guessing.
+- **Auto-importing remote tags/bookmarks during `git.fetch()`.** jj v0.44's
+  headline change is that `jj git fetch` now fetches tags the same way it
+  fetches bookmarks — as `<name>@<remote>`, auto-tracked by default. Wiring
+  that up properly for tags would need `git.fetch()` to actually populate
+  `TagStore`'s (and, by the same logic, `BookmarkStore`'s) remote-tracking
+  state from the fetched refs. Investigating this surfaced a **pre-existing**
+  gap: `git.fetch()` already doesn't call `bookmarks.setRemote()` for fetched
+  bookmarks today, even though `BookmarkStore.setRemote()`/`getRemote()` have
+  existed since v0.4 — remote ref sync was never wired all the way through at
+  the fetch call site. Building tag-fetch-tracking on top of that gap would
+  mean either (a) fixing the older bookmark gap too as a drive-by, our
+  papering over an inconsistency where tags "worked" and bookmarks didn't, or
+  (b) building a second, tag-only special case. Both are judgment calls
+  about a real architectural gap, not a mechanical port of one version's
+  changelog — left for a maintainer to decide. `tag.track()`/`untrack()`
+  (added this pass) at least let callers record and query tracking intent by
+  hand in the meantime.
+- **`jj git clone --tag=PATTERN` / `--fetch-tags` removal.** Real jj replaced
+  `--fetch-tags=all|none|included` with `--tag=PATTERN` in v0.44. isojj's
+  `git.clone()`/`git.fetch()` never exposed CLI-shaped `--fetch-tags` flags in
+  the first place (just a boolean `noTags`), so there's no removed flag to
+  mirror; a `PATTERN`-based tag filter for clone/fetch would be new surface
+  area tied to the fetch-tracking gap above.
+- **`jj git push --allow-conflicts`.** Real jj normally refuses to push
+  commits containing conflicts unless this flag is passed. isojj's
+  `git.push()` doesn't currently check for conflicts before pushing at all —
+  there's no existing guard to add a bypass flag for. Adding the guard itself
+  (and then the bypass) is more surface area than a one-version parity pass.
+- **CLI argument parsing "last occurrence wins" (v0.44).** Checked
+  `bin/isojj.js`'s `parseArgs()`: it already stores each `--flag` into a
+  plain object keyed by flag name, so repeating a flag already naturally
+  overwrites the earlier value with no error — this was already jj v0.44's
+  new behavior by construction. No change needed.
+- **`try(expr, fallback...)` template function, `jj workspace list` root
+  display, `diff.stat.max-bar-width`, `colors.crossed-out`, Gerrit/config-gc/
+  `/etc/jj` config-discovery changes.** These are jj's template engine and
+  terminal/config-file layers, which isomorphic-jj's CLI (a thin, generic
+  API-argument passthrough — see `bin/isojj.js`) doesn't attempt to replicate
+  1:1 for any command. Out of scope for this pass; noted here for
+  completeness of the v0.43/v0.44 diff.
+
+## 0.0.0
+
+- **Renamed: `isomorphic-jj` is now `@johnhenry/isomorphic-jj`, restarted at 0.0.0.** Same library, same API — a new address and era, not a maturity signal (1.7.0 lineage).
+
+  ```sh
+  npm install @johnhenry/isomorphic-jj
+  ```
+
+
 All notable changes to isomorphic-jj are documented here. The project tracks the
 [Jujutsu (jj)](https://github.com/jj-vcs/jj) CLI; each release notes the upstream
 jj version whose semantics it targets.
@@ -171,7 +593,9 @@ adds a batch of revset functions and commands, and cleans up the toolchain.
 - `forks()` — changes with more than one child.
 - `first_parent(x)` / `first_ancestors(x)` — first-parent navigation (jj v0.32).
 - `fork_point(x)` — youngest common ancestor of a set (jj v0.32).
-- `merge_point(x)` — youngest common descendant of a set.
+- `merge_point(x)` — youngest common descendant of a set (implemented ahead of
+  upstream; jj stabilized its own `merge_point()` in v0.44 with matching
+  semantics — "the point where multiple branches merge").
 - `exactly(x, n)` — the set, but errors unless it has exactly `n` elements (jj v0.34).
 - `present(x)` — evaluate without erroring on unknown symbols.
 - `coalesce(a, b, …)` — the first argument that resolves to a non-empty set.

package/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2025 [fullname]
+Copyright (c) 2025 John Henry
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal