Tracking issue for colocated workspaces
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 enableandjj git colocate disable[ TODO ] - [ ] ○ (4) Add add colocation support to
jj workspacesubcommands [ 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:
- 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;- when switching back and forth between workspaces, Jujutsu seems to reimport the state from Git, which creates a lot of duplicate changes;
- 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.
- (4) Add add colocation support to
jj worktreesubcommands
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.
There's no such thing. It should be add colocation to
jj workspacecommands.
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.
I guess I’ll create a Discord account soon™
There is an IRC channel #jujutsu with a discord bridge.
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 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 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.