jj icon indicating copy to clipboard operation
jj copied to clipboard

Tracking issue for colocated workspaces

Open ejpcmac opened this issue 1 month ago • 5 comments

This is a tracking issue for the Colocated Workspaces feature.

Background and summary

Please see https://github.com/jj-vcs/jj/issues/4436.

Steps

  • [ ] @ (1) Finalise and merge https://github.com/jj-vcs/jj/pull/8252 [ ONGOING ]
    • [x] @ Rebase https://github.com/jj-vcs/jj/pull/4644 and create a new PR [ DONE ]
    • [ ] ○ Fix the review comments and any other issue [ TODO ]
    • [ ] ○ Merge to main [ TODO ]
  • [ ] ○ (2) Refuse to create a new Jujutsu repo in a Git worktree when running jj git init --colocate [ TODO ]
    • [ ] ○ TODO: Check that it is still the case
  • [ ] ○ (3) Add workspace support to jj git colocate enable and jj git colocate disable [ TODO ]
  • [ ] ○ (4) Add add colocation support to jj workspace subcommands [ TODO ] See: https://github.com/jj-vcs/jj/pull/4588
  • [ ] ○ (5) Add support for multiple Git heads to avoid re-importing when switching workspaces [ TODO ] See: https://github.com/jj-vcs/jj/pull/4588

Side quests

  • [ ] Write a stopgap CLI command (not to be merged) to enable creating colocated workspaces for real-world test purpose

Notes

Step (1) will bring internal support for colocated workspaces, but the MVP must include steps (2) and (3) to be usable.

Step (5) will solve an inconsistency and annoyance with the git_head(). To quote myself:

After my first experiments, I’m seeing three things I’d like to fix:

  1. when a workspace is not colocated, jj log still shows the git_head() from the @default workspace, which is IMO misleading. git_head() is properly updated once the workspace is colocated;
  2. when switching back and forth between workspaces, Jujutsu seems to reimport the state from Git, which creates a lot of duplicate changes;
  3. this one is certainly related to (1) and (2): if we create a new non-colocated workspace, git_head() points to the Git HEAD from the latest visited colocated worktree, which does not give a consistent result.

Note to maintainers: if such a tracking issue does not seem appropriate to you, please close it.

ejpcmac avatar Nov 17 '25 14:11 ejpcmac

  • (4) Add add colocation support to jj worktree subcommands

There's no such thing. It should be add colocation to jj workspace commands.

(3) Add workspace support to jj git colocate enable and jj git colocate disable

We had a discussion about this recently in the Discord here. The behavior everyone agreed on is to make it configurable per workspace, while having some config option like the original #4588 may also be nice.

PhilipMetzger avatar Nov 17 '25 22:11 PhilipMetzger

There's no such thing. It should be add colocation to jj workspace commands.

Oops. It was a mistype.

We had a discussion about this recently in the Discord here. The behavior everyone agreed on is to make it configurable per workspace, while having some config option like the original https://github.com/jj-vcs/jj/pull/4588 may also be nice.

This is what I meant, like jj git colocate enable would only impact the current workspace.

I guess I’ll create a Discord account soon™, after years managing to avoid it 😅 It will be easier for quick questions or discussions.

ejpcmac avatar Nov 17 '25 22:11 ejpcmac

I guess I’ll create a Discord account soon™

There is an IRC channel #jujutsu with a discord bridge.

apoelstra avatar Nov 18 '25 13:11 apoelstra

Status update

Work done

I have just finished the rebase of #4644 as #8252. It was a little bit of work to update all the tests to use the new test utils, but it was a great opportunity to understand better the code and what we are testing.

This PR enables Jujutsu to detect a colocated workspace, but there is no command to create one yet. It is also still a WIP, as there were review comments on the previous PR I’ll need to fix, plus a few refactoring opportunities I’m seeing as well.

Next steps

I’ll first write a tiny / hacky CLI command to create colocated workspaces on top of this PR as a side quest before getting back to the PR itself. This will enable me to have a way to test the code on real-world usage and better see rough edges.

Then, I’ll proceed with the remaining steps as defined in the first message of this issue.

ejpcmac avatar Dec 07 '25 15:12 ejpcmac

@ejpcmac i'd love to help test/hack on this with you, I am starting to be really blocked by not having this feature. Let me know how I can help out.

LucioFranco avatar Dec 13 '25 18:12 LucioFranco

@LucioFranco I’ve had a bit of delay due to other life priorities, so I’m starting this week to work on the stopgap command to bring a minimal usage from the CLI.

If you want to help, would you be interested in listing all the corner cases related to workspace colocation detection (more prio) and CLI commands (less prio), and draft a spec of what should we do in each case?

By this I mean things like a Jujutsu workspace with another, non-colocated Git repo inside the workspace. Or a Jujutsu repo in a Git worktree, colocated or not. Having a comprehensive list of all those cases would help to ensure we have proper test coverage, and that we are all aligned on the behaviour we expect from Jujutsu.

ejpcmac avatar Dec 17 '25 20:12 ejpcmac