Jujutsu support

[jennings]

Adds support for Jujutsu repositories. Jujutsu (jj) is a git-compatible version control system. It has the concept of "workspaces" which are analogous to git worktrees.

Jujutsu repositories can be colocated with git repositories (the .jj directory is a sibiling of the .git directory it uses as its backing storage), so a directory may be both a Git repository and a jj repository. If so, prefer the jj repository.

• Add a vcs.Backend interface that is implemented by both git.GitBackend and jujutsu.JJBackend.
• When creating a worktree, prefer instead to create a Jujutsu workspace with jj workspace if in a jj repository.
• Display in the preview window whether it is a Git Worktree or a Jujutsu Workspace.

[Abeansits]

@jennings love the initiative!

Just a couple of questions:

• how do you avoid the issue of agent's "natural tendency" to use git instead of jj?
• how do you avoid the issue of having multiple agents pushing (jj git push) to the same repo causing lock contention?

[jennings]

• how do you avoid the issue of agent's "natural tendency" to use git instead of jj?

To be honest, I haven't thought that much about it yet. I don't really ask the agent to commit things very often. I know this is a common workflow, though, and people have had success putting instructions in their AGENTS.md to use jj instead of git.

Perhaps it should be a config setting prefer_jujutsu or something, instead of automatically preferring jj workspaces over git worktrees in a colocated repo.

• how do you avoid the issue of having multiple agents pushing (jj git push) to the same repo causing lock contention?

If you really mean pushing, then I think it has the exact same problems as pushing from a git worktree. Remotes can't tell if git or jj are pushing to them (other than the fact that the commits they're receiving usually have an extra change-id header). In fact, pushing and fetching are actually handled by executing git commands.

However, I think you may mean just "updating the (local) repo with changes", similar to git commit. jj's data structures support concurrent access. However, the underlying git repo doesn't and so jj acquires a lock on it.

[Abeansits]

• how do you avoid the issue of agent's "natural tendency" to use git instead of jj?

To be honest, I haven't thought that much about it yet. I don't really ask the agent to commit things very often. I know this is a common workflow, though, and people have had success putting instructions in their AGENTS.md to use jj instead of git.

Perhaps it should be a config setting prefer_jujutsu or something, instead of automatically preferring jj workspaces over git worktrees in a colocated repo.

nice! the flag you mention seems like a must, we can't have a mix of worktrees and workspaces in the same repo, right? this is explicitly forbidden in the docs for jj

• how do you avoid the issue of having multiple agents pushing (jj git push) to the same repo causing lock contention?

If you really mean pushing, then I think it has the exact same problems as pushing from a git worktree. Remotes can't tell if git or jj are pushing to them (other than the fact that the commits they're receiving usually have an extra change-id header). In fact, pushing and fetching are actually handled by executing git commands.

However, I think you may mean just "updating the (local) repo with changes", similar to git commit. jj's data structures support concurrent access. However, the underlying git repo doesn't and so jj acquires a lock on it.

sorry didn't explain myself very well, to my understanding if you're using workspaces in a co-located repo, while having multiple agents making changes then jj is forced to sync w the underlying git repo on every change, thus creating potential lock contention in the git store
I might be missing something here, but it seems like this is what the docs are referring to in this section

does that make more sense?

[jennings]

we can't have a mix of worktrees and workspaces in the same repo, right? this is explicitly forbidden in the docs for jj

You can use worktrees and workspaces in the same repo. I am doing it today with Agent Deck and other similar tools.

What I think you're referring to is that only the default workspace (the first one you get when you jj git clone) can be colocated with git. Any additional workspaces are not colocated, so git commands can't be used in them. It still stores everything in the git repo, it just isn't a git worktree.

This isn't a fundamental limitation, I expect this feature to be added sometime. Several people have started work to make workspaces also contain git worktrees, but it seems it's more work than you'd expect.

while having multiple agents making changes then jj is forced to sync w the underlying git repo on every change, thus creating potential lock contention in the git store

I think you might be worried that every change to any file might trigger a snapshot (amend the working copy commit).

There is no daemon watching files on disk get changed, by default. Instead, each time you run any jj command, the first thing jj does is the equivalent of git commit --amend -A. So, the sync only happens when the agent or human chooses to run a jj command. This is the same amount of contention that git worktrees have because they're all operating on the same object and ref storage.

There is an optional integration with watchman to automatically snapshot when files are edited, but it's not on by default.

I might be missing something here, but it seems like this is what the docs are referring to in this section

I think this is the same problem you'd have using git over NFS, no? The jj storage should be safe over NFS, the warning is referring to git not being fully safe to use concurrently.