Jujutsu (jj) support

[KingMob]

It would be great if worktrunk supported Jujutsu workspaces, too.

[max-sixty]

I'm open to this! I don't know much about JJ beyond just "people love it".

To what extent are the concepts transferable? Is it just "replace all the git commands with equivalent jj commands"?

[KingMob]

Hmm, it's 90-95% similar, I'd say, but it's not drop-in. See https://docs.jj-vcs.dev/latest/git-compatibility/#supported-features for the complete git interop list. I think most of the bread-and-butter commands would work with minimal change, but there's some deep assumptions that are different (working copy, branches).

From wt's perspective, I think these would be the key points/differences:

1. jj workspaces == git worktrees, but even though jj uses git under the hood, workspaces are not built off worktrees iiuc
2. The working copy is like an automatically-updated commit; no staging area
3. jj doesn't require branches have names; named branches can be approximated with "bookmarks", but unlike git branch names, bookmarks don't automatically get moved with HEAD when new commits are added. This can be mimicked, but requires manually moving the bookmark (see the common jj tug alias).
4. No git hook support yet. Because of (2), they're still figuring out how hooks should work (can't naively run pre-commit hooks if you snapshot into the working copy commit on every file change). See jj hook issue and the jj discord for more.
5. Minor point: jj users tend to rebase a lot more than under git for a variety of reasons (safer, stable change IDs, better history rewriting abilities)

---

I forked worktrunk to explore this yesterday, but I have no findings or results yet.

[max-sixty]

thanks, though the most helpful thing would be a comparison of how things map for Worktrunk. if anyone who knows jj & worktrunk well wants to take a swing at that, would be great, thanks in advance

[KingMob]

You mean like a table mapping wt commands to jj-based equivalents?

If I have some spare time (a big if sadly), I could do that.

[max-sixty]

yes, to some extent

wt commands would presumably remain the same; then the challenge for us it to work out which jj commands we need to call instead of the current git commands... (unless others have other ideas for how to do this)

[KingMob]

This is written with the following assumptions:

1. We wouldn't try to mimic named branches. It's doable with a certain amount of ceremony (making jj bookmarks, and then manually updating them), but that's not really how people use jj. Not sure if this is a blocker or not, because git revolves around named branches. To identify the main/master HEAD, we typically use the trunk() revset. This is the single biggest mismatch though, that git uses named branches as a fundamental organizing principle, while jj doesn't really care.
2. I don't know how worktrunk handles the primary repo workspace's path or paths in general. In jj, the primary workspace is named default, but a) it can be renamed, and b) the call to look up a path from a name only works for workspaces created with jj 0.38+. This is fine for new workspaces, but it means the default workspaces of a lot of repos will predate that, and thus fail. We might have to store the main workspace path in another way. The examples below show looking it up with jj workspace root --name default for now.

Core Commands

Task	Worktrunk	jj	Notes
Switch worktrees	wt switch feat	cd "$(jj workspace root --name feat)"
Create + start Claude	wt switch -c -x claude feat	jj workspace add --name feat ../repo.feat && cd "$(jj workspace root --name feat)" && claude
Clean up	wt remove	cd "$(jj workspace root --name default)" && rm -rf "$(jj workspace root --name feat)" && jj workspace forget feat
List with status	wt list	jj workspace list (names + commits)

---

wt switch

Task	Worktrunk	jj	Notes
Switch to existing branch worktree	wt switch feat	cd "$(jj workspace root --name feat)"
Create new worktree	wt switch --create feat	jj workspace add --name feat ../repo.feat && cd "$(jj workspace root --name feat)"	New workspace starts with a fresh change on @
Create from specific base	wt switch --create fix --base release	jj workspace add --name fix --revision release ../repo.fix && cd "$(jj workspace root --name fix)"
Switch to default branch	wt switch ^	cd "$(jj workspace root --name default)"
Switch to PR branch	wt switch pr:123	jj git fetch && jj workspace add --revision <PR revision> ...	Not super sure on this one, I never use gh

---

wt list

In a lot of cases, we'd have to show change IDs instead of branches.

Task	Worktrunk	jj	Notes
List worktrees	wt list	jj workspace list
List with full details	wt list --full	jj workspace list + jj log in each
Include branches without worktrees	wt list --branches	jj log -r 'heads(all())'	Show all head revisions. We could use bookmarks() if we wanted those instead
Include remote-only branches	wt list --remotes	jj log -r 'remote_bookmarks(remote=origin)'	Remote tracking refs
JSON output	wt list --format=json	jj log --template ... (custom templates)	jj has super-powerful templates
Show uncommitted changes	+ in Status column	jj status	In jj all changes are committed; this shows the working-copy diff
Show ahead/behind main	main↕ column	jj log -r 'trunk()..@'
Show ahead/behind remote	Remote⇅ column	jj log -r 'remote_bookmarks(remote=origin)..@'

---

wt remove

Not sure what directory you end up in if you delete the current workspace, so I assumed we'd jump to the default.

Task	Worktrunk	jj	Notes
Remove current worktree + branch	wt remove	cd "$(jj workspace root --name default)" && rm -rf "$(jj workspace root --name feat)" && jj workspace forget feat	Commits remain in history; jj workspace forget just forgets the working copy associated with a workspace
Remove specific worktree	wt remove feat	cd "$(jj workspace root --name default)" && rm -rf "$(jj workspace root --name feat)" && jj workspace forget feat
Force remove (unmerged branch)	wt remove -D	cd "$(jj workspace root --name default)" && rm -rf "$(jj workspace root --name feat)" && jj workspace forget feat	No distinction in jj — unmerged work is just commits in the graph
Remove but keep branch	wt remove --no-delete-branch	cd "$(jj workspace root --name default)" && rm -rf "$(jj workspace root --name feat)" && jj workspace forget feat	Same as above — there's no named branch to delete

---

wt merge

Task	Worktrunk	jj	Notes
Merge feature into main (squash)	wt merge	jj new 'trunk()' && jj squash --from 'trunk()..feat' --into @ && jj bookmark set main -r @	Squashes all changes from feat into one commit on main
Merge to specific branch	wt merge develop	jj new 'develop' && jj squash --from 'develop..feat' --into @ && jj bookmark set develop -r @	(Assumes develop is a bookmark and not a general revset)
Merge without squash	wt merge --no-squash	jj rebase -d 'trunk()' then usual workspace removal	Keeps individual commits

This is not the complete yet, but I figured I'd paste for comment so far.

[KingMob]

wt step

--stage doesn't make much sense for many of these options, since there's no staging area in jj. To keep a file out of a commit requires putting it in .gitignore (and maybe running jj file untrack after updating gitignore).

commit

Task	Worktrunk	jj	Notes
Stage all + commit	wt step commit	jj commit -m "message"
Stage tracked only	wt step commit --stage=tracked	jj commit -m "message" <fileset>	--stage all/tracked/none doesn't make sense for jj, but you can specify a fileset to indicate which files should be in this commit, and which kept in the new child commit

squash

Task	Worktrunk	jj	Notes
Squash all commits since branching from trunk	wt step squash	jj squash --from 'trunk()..feat' --into 'roots(trunk()..feat)	Squashes all branch commits into the first commit after branching off
Squash tracked	wt step squash	jj squash --from 'trunk()..feat' --into 'roots(trunk()..feat) <fileset>	Same as above, but only for matching files

rebase

Task	Worktrunk	jj	Notes
Rebase onto trunk branch	wt step rebase	jj rebase -b feat -d 'trunk()'	Rebases whole branch feat onto trunk()

push

Task	Worktrunk	jj	Notes
Fast-forward	wt step push	jj bookmark move main --to feat

---

wt hook

The hooks seem like they should work, since they are wt hooks, not git hooks, which jj doesn't support yet.

[drusellers]

oh man, would love to see JJ support

[max-sixty]

I started on this but paused, will try to restart again. It's a very large code change to do it well, so I can't promise anything...

If anyone else would like to do it, please don't let me get in the way (but it needs to be done quite thoughtfully, we can't point an agent and be like "add JJ make no mistakes"...)

I found @KingMob 's summaries above v high quality, thank you

[KingMob]

Thanks, max.

For anyone wanting to use these tables, I tried to be comprehensive and thorough, but be sure to verify them.

[pablospe]

There might be a lighter path to jj support worth considering. Worktrunk is built on git worktrees, and the current discussion assumes we'd need to replace all the git plumbing with jj equivalents (jj workspaces, bookmarks, etc.) — which is a huge effort.

But jj-vcs/jj#8667 adds colocation-aware git worktree support to jj. Once that lands, jj's GitBackend will properly detect and operate on git worktrees — updating HEAD in the correct worktree, etc.

This means wt could potentially keep doing exactly what it does today — managing git worktrees — and colocated jj users would get support essentially for free. jj would correctly understand the git worktrees that wt creates without wt needing to learn any jj commands.

The tradeoff is this only works for colocated repos (jj with git backend), not pure jj — but that's the vast majority of jj usage today.

This wouldn't cover jj-native workflows (jj workspaces, revsets, etc.), but it could be a pragmatic first step that gives jj users a working experience with minimal changes to worktrunk.

[KingMob]

It would certainly be handy if jj understood git worktrees. I'm not sure it would be 100% drop-in though.

Parts of the worktrunk git-based workflow still won't apply as is. E.g., anything to do with staging/committing, but those can be no-ops. I suppose it really depends on the details of how git worktree interop will actually behave.

---

FYI, this work has been ongoing for over a year, I'm not sure it's as close to completion as we might think. I believe this is the correct tracking issue; there's a lot of duplciation.