■ space · the two timelines

■ the answer first

jj records every operation in an op log; jj undo walks back a wrong rebase or reset — git's reflog only rescues commits.

Git-compatible by default storage: one clone, both tools — remotes, forges, CI keep working.

The record says: try it colocated on a side project; not a big-bang migration — it's 0.x, breaking changes ride monthly releases.

THE TWO TAPES

Press operations. The commit tape (git) and the operation tape (jj) record side by side — then try to take the last one back.

the tapes are empty — press an operation.

GIT · the reflog — commits, ~90 days

    the reflog has no opinion about the sequence of commands that produced the mess — you pick the reverse command yourself: reset? revert? cherry-pick?

    JJ · the op log — every operation

      "because everything is recorded, you can undo that mistake you just made with ease" — the README's own line. jj op log · jj undo.

      Git's undo story assumes you'll pick the right command. jj's assumes you won't.

      WHAT JJ IS, FROM THE RECORD

      jj is a Git-compatible VCS: 31,796 GitHub stars, 376 contributors, first release December 2020, a release every single month since

      v0.35 (November 2025) through v0.45.1, September 2026, twelve releases, clockwork.

      "Git-compatible" is the part people miss: jj uses a Git repo as its default storage — commits and files live in git's format. Clone, remotes, forges and CI keep working.

      The "jujutsu vs git" search is the wrong frame: jj is a new interface bolted onto the storage you already trust.

      (Meta's Sapling bet the other way — its own storage — and costs more of the git ecosystem.)

      CONFLICTS YOU CAN COMMIT

      Yes — conflicts are first-class objects, and it matters more than the undo story. Git treats a merge conflict as a temporary working-tree state: resolve now or abort.

      jj stores conflicts in history: a conflicted commit can exist, be committed, even pushed.

      Resolve later; jj propagates the fix to every descendant — the same mechanism that rebases your stack.

      "Stacked PRs with multi-branch rebases are effortless. Conflicts are actual things in the history that you can come back to later. Everything is automatically committed, so I don't lose work from a bad reset/stash pop." — hellcow, Hacker News on jj patterns (236 points)

      That last sentence is the one: jj's working copy is itself a commit, amended on every change.

      There is no stash, because there is nothing to stash — switching branches carries your work as a commit.

      Another switcher at a git-only workplace: "there were 0 issues."

      WHAT THE RECORD SAYS AGAINST JJ

      SHOULD YOU SWITCH?

      The verdict, and the honesty line: I've read the record, not run it.

      Every number and quote here comes from the repository, its README and the Hacker News thread — not my terminal.

      What the record supports: try jj colocated on a side project — one clone, both tools, zero migration. Git knowledge transfers; teams adopt per-person, since jj pushes ordinary git commits.

      What it doesn't: a big-bang migration of an established team, or trusting a 0.x tool with release-critical automation before a pin-and-soak period.

      The undo gap is real, the design coherent, interoperability removes the excuse — leaving habit.

      Would you trade a weekend of muscle memory for an undo log covering the tool itself?

      And honestly — when did you last lose work to a reset? Did the reflog get everything?

      ■ honest stamp I've read the record, not run it. Tested on: the public record — jj v0.35 → v0.45.1 · git 2.4x reflog. Recorded 2026-09-29, refreshed 2026-10-04. Stars, contributors, release cadence, the bookmark caveat, both HN quotes and the README line come from the repository, its README and the linked public thread. The two tapes above are a design diagram, not a bench — they illustrate what each log records, no timings claimed.

      end of the two timelines · nothing fetched · everything local