Originally published on Mr Say Nothing.
tl;dr
- v0.46.0 shipped six days ago — jj workspaces now colocate through real git worktrees, and cross-workspace
jj undois refused by default. Safer, not just newer.- The fortnight record, from our own two reads: 31,796 → 32,012 stars, a 34-day release cadence, and a repository pushed the morning this was written.
- Your repo stays 100% git. Colocated, GitHub and your teammates see a plain git repository — the switching cost is muscle memory, not migration.
second read: the v0.46.0 release notes + the repo record · **record-read, not benched* — the timed jj-vs-git bench is still owed*
Two weeks ago this site read jj's record for the first time and called it the undo button git never had — 31,796 stars, monthly releases, one operation log. Today the second read: 32,012 stars (+216 in the fortnight), v0.46.0 shipped six days ago, and the repository was pushed at 05:22 this morning, UTC, before the kettle was on.
The honesty line, same as last time: I've read the record, not run it. Everything below comes from the v0.46.0 release notes, the repository's public record and our own first read. What a second read adds is the thing first reads can't have: a delta. Two weeks of releases, two weeks of stars, two weeks of our own search data piling up behind the same question.
And the lie this piece refuses: that a version number is news. Most point releases are plumbing. v0.46.0 is not — it changes the switching calculus, and the fortnight's demand data explains why that matters more than the changelog admits.
What changed in Jujutsu v0.46? Workspaces can now colocate through real git worktrees (
jj workspace add --colocate),jj undo/jj redorefuse cross-workspace operations by default,jj bisect runsanity-checks its endpoints, and the minimum git rose to 2.42.0. Colocated repositories remain plain git to GitHub and teammates.
The fortnight record
Numbers first, because they are the only part of this piece nobody can argue with.
| the measure | first read (29 Sep) | second read (13 Oct) |
|---|---|---|
| GitHub stars | 31,796 | 32,012 (+216 / 14 days ≈ 15/day) |
| latest release | v0.45.1 (3 Sep) | v0.46.0 (7 Oct — a 34-day gap) |
| repository last pushed | active | 05:22 UTC today |
| open issues | — | 1,260 |
Stars are vanity, cadence is signal: two releases inside six weeks with breaking changes properly listed is a project that ships and tells you what it broke. The 1,260 open issues read the same way — a moving tool, not a finished one.
Our own ledger carries the second signal. The single biggest impression family on the git cluster this month is still undo a commit but keep the changes — impressions up 100% week over week, and almost zero clicks, because the honest git answer runs three commands deep and readers can tell. The demand for undo did not wait for jj. It never does.
Jujutsu vs git: the undo table
The first read explained the model — the working copy is a commit, every operation writes to the operation log, conflicts are first-class. What it skipped, and what the search data says people actually need at 6am, is the phrase-level table: the job, typed the way searchers type it, in both dialects.
[the two ledgers side by side: git remembers where refs pointed; jj remembers what you did.]
| the job | git (the incantation) | jj (the operation) |
|---|---|---|
| undo the last thing I did | reflog, squint, reset --soft or reset --keep
|
jj undo |
| undo the undo | there is no clean path | jj redo |
| see what just happened | git reflog |
jj op log |
| amend the last commit | git commit --amend |
edit the files — the working-copy commit amends itself |
| hold a conflict for later | not allowed — resolve now or stop | conflicts are commits; resolve any time |
In git, undo is archaeology — dig through the reflog, find the shard, rebuild. In jj, the tape was never buried: undo is an operation on the log of operations. Excavation versus a rewind button.
Picture it: git gives you the flight recorder — mounted behind the plane, readable after the crash. jj mounted it on the dashboard and wired it to a rewind button.
v0.46.0: the two changes that matter
Workspaces that colocate through real git worktrees. jj workspace add --colocate (or the git.colocate setting) puts a jj workspace beside a plain git checkout without taking the clone over. Read that as the on-ramp widening: a team can run one jj workspace next to a git checkout on the same machine, the same repository, and compare — which is exactly the trial the first read's verdict asked for. It leans on git worktree add --orphan, which is why the minimum git rises to 2.42.0.
Undo that knows its boundaries. jj undo and jj redo now refuse to touch operations from another workspace unless you pass --allow-cross-workspace. A tool whose entire pitch is "undo is safe" tightening the guards around undo is the culture test passing. The rest of the notes read the same way: jj bisect run checks its good and bad endpoints before walking, and jj split stops juggling editor sessions.
Try the recorder without risking anything: in a throwaway clone, run jj git init --colocate — a .jj directory appears beside .git, git keeps working exactly as before, and jj op log shows the recorder running. Nothing about the git side changes; the door out is rm -rf .jj. Verify: jj op log in that clone lists your operations with timestamps — one line per command means the ledger is real on your box, not just in the docs.
The honest ledger: what breaks
Muscle memory, first. The index dance — git add -p, partial staging — maps to jj's squash and split, which solve the same problem with different hands. For the first week you will type git verbs and be annoyed.
Team optics, second. Colocated repositories look like plain git to hosting and to teammates — but a jj user's working-copy commits only become visible when pushed, and "where is my half-finished work" gets a different answer than git people expect. Small teams shrug; monorepos with deep tooling should wait. v0.46's cross-workspace undo refusal is one more boundary to learn — deliberately, and honestly, the right call.
And the receipt still missing: benchmarks. Two reads in, the claim remains unmade. I cannot tell you jj's rebase beats git's on a 10,000-commit repository, because I have not run it — that number does not exist until the bench does, and a second read does not turn a record-read into a bench.
Verdict, revised: who should move this week
The first read said: trial it. Two weeks and one release later, the calculus moved in exactly one direction — v0.46's worktree colocation lowered the cost of the trial itself, and the demand data hardened. The undo family our board tracks did not cool by a single impression; the tool that answers it in one command shipped twice. When a gap that wide keeps widening, someone is going to close it. jj is closing it at the model level, not the mnemonic level — the full comparison sits on the git-undo hub, beside the classic decision it disturbs: revert vs reset, which now has a third answer, and the third answer is a button.
Move now: solo developers and small teams with undo scars; anyone who teaches git and is tired of watching faces fall at reflog; and — the lane we watch most closely — agent-run repositories, where every operation should be reversible and auditable by default. An operation log is not a convenience there; it is the audit surface git never shipped.
Wait: deep git tooling chains, hook-heavy CI assumptions, anyone mid-migration. And wait for the bench — this site's own next jj piece runs jj against git on a real repository and prints the ugliest number first, because the fortnight record bought the benefit of the doubt exactly once.
Two questions before that bench: has a reflog rescue ever failed you at the worst possible moment — and if you run jj in anger this month, what breaks first? The comments are open; tell us what to test.
Cross-posted from Mr Say Nothing, where the timed jj-vs-git bench lands when it exists — the ugliest number prints first.
Top comments (3)
The fortnight numbers, for anyone who wants the receipts: 31,796 → 32,012 stars (+216, about 15 a day), v0.46.0 landing 34 days after v0.45.1, and the repo pushed at 05:22 UTC the morning this went up. The row that surprised us most is the 1,260 open issues — cadence is signal, and issues read the same way: a moving tool, not a finished one.
Honest question for people already living in jj: which git habit took you longest to unlearn — partial staging, or thinking in branches instead of changes?
@kyisaiah47 there is no per-workspace operation store to expose — all workspaces share the repo's single op log, so jj op log reads the same history from any workspace, with each operation recorded as belonging to the workspace that made it. What stays per-workspace is only the working-copy commit (@) and that workspace's checked-out tree. Colocation does not change the picture: the .git sidecar shares refs, not op state — the op store stays on the jj side under the primary workspace.
How does a colocated workspace expose the original checkout's operation store through
jj op log?