Any interest in adding support also for jj / jujutsu?

[sundbp]

I've found jj to be a very good match for working with AI agents - the oplog, ability to undo, the simpler model around working copy that removes stashing and so forth are all (subjectively) helpful in this setting.

jj workspaces and git worktrees are fairly similar concepts, and most of the git operations that workmux uses have equivalents in jj.

If there's interest in this I did first cut of jj support on this branch that I'd be happy to test and get into sufficiently good shape for inclusion:
main...sundbp:workmux:main

[rytswd]

I found the lack of jj support was one big reason for not being able to use workmux everywhere personally. I'd love to see this added, and would be happy to contribute if any help is needed!

[sundbp]

Feel free to give the branch above a spin @rytswd :)

[rytswd]

Sorry for the delay, I finally had a chance to test this. I got a bunch of errors with a brand new jj repo with git colocation.

Summary

When using workmux with a colocated jj+git repository, workmux add fails with "No main worktree found" because jj resets .git/HEAD to refs/jj/root after every operation, and workmux (via git worktree internals) cannot recognize this as a valid checkout.

Environment

• workmux 0.1.129
• jj (Jujutsu) with colocated git backend
• PR Add support for using jj and jj worspaces #71 (sundbp/workmux) — adds jj workspace support

Steps to Reproduce

1. Create a colocated jj+git repo:

   jj git init --colocate

2. Make a commit and set a bookmark:

   echo "hello" > README.md
   jj describe -m "initial commit"
   jj bookmark create main -r @

3. Verify .git/HEAD:

   cat .git/HEAD
   # Shows: ref: refs/jj/root

4. Try workmux add:

   workmux add my-feature --background --prompt "test"
   # Error: No main worktree found

Root Cause

In a colocated jj repo, .git/HEAD always points to refs/jj/root — a special internal ref that jj uses to manage its own state. This is by design in jj's colocated mode.

However, workmux's git worktree detection (likely git worktree list or git rev-parse) uses .git/HEAD to determine the "main worktree" and its checked-out branch. Since refs/jj/root is not a real branch under refs/heads/, workmux cannot identify the main worktree.

Every jj operation resets .git/HEAD back to refs/jj/root, even if you manually fix it with git symbolic-ref HEAD refs/heads/main. This means any workaround is fragile — it breaks as soon as jj runs again.

Additional Issue: --base Required

Even after fixing .git/HEAD, workmux add fails with:

Failed to determine the current branch to use as the base
No bookmark on current change

This happens because jj's working copy is typically an unnamed child commit (not directly on a bookmark). The workaround is --base main, but this shouldn't be necessary when there's only one obvious base.

Workaround

# Fix HEAD before every workmux call
git symbolic-ref HEAD refs/heads/main

# Use --base to explicitly specify the base
workmux add my-feature --base main --background --prompt "..."

This workaround is fragile because any subsequent jj command resets HEAD.

Suggested Fix for PR #71

The JjVcs implementation in the PR should handle these cases in its VCS trait methods:

1. get_main_workspace_root(): Should use jj workspace list to find the "default" workspace path rather than relying on git's worktree detection. The default workspace IS the main workspace in jj.

2. get_current_branch(): When called from the main workspace context (for determining the base branch), should handle the case where @ has no bookmark by falling back to the parent's bookmark or the configured main_branch.

3. detect_vcs() priority: The PR correctly prefers jj over git when both .jj/ and .git/ exist (colocated). But the downstream code paths that call git-specific functions (like resolving the main worktree for tmux window management) may still be hitting the git codepath.

4. Consider not using git worktree at all for jj repos: The PR's create_workspace() correctly uses jj workspace add, but the "main worktree" detection might still go through git internals. For jj repos, the main workspace should be resolved entirely through jj workspace list (the "default" workspace entry).

Test Case

# In a fresh colocated jj repo with a bookmark
jj git init --colocate
echo "test" > file.txt
jj describe -m "init"
jj bookmark create main -r @

# This should work without any git HEAD manipulation
workmux add feature-a --background --prompt "test"
workmux list  # Should show main + feature-a
workmux remove feature-a --force

[PrayagS]

Is this specifically for repos that only use jj and are not colocated with git? Because I haven't had any real issues with using workmux in colocated repos. I use jj commands in the main worktree.

Also interested in knowing how jj workspaces compare to git worktrees in your experience.

[german-quantica]

For me the lack of jj workspaces support was a big drawback, otherwise looks like a great tool.

[rytswd]

The only difference I know about worktree vs workspace is the branch checkout restriction -- workspace doesn't care if you have the same branch checked out from multiple workspaces, whereas worktree only allows a single worktree to be working on the same branch. Technically that won't be too much of an issue as long as you have workflow setup so that the new branch is always created before starting up the worktree, but I prefer having the same "main" branch checked out in multiple contexts for debugging / testing.

I couldn't make the colocated git repo to work directly -- maybe it had to do with how I used it, but I got into issues where commits would move sideways as I change files outside of the agent session, and the agent gets really confused and start making random commits.