Colocated workspaces, minimal

[cormacrelf]

Only the worktree recognition and HEAD reading/writing parts of #4588.

In other PRs:

• The CLI changes: create/destroy git worktrees during jj workspace add/forget
• The view changes to track multiple git heads and make the git_head() revset work correctly

Checklist

If applicable:

• [ ] I have updated CHANGELOG.md
• [ ] I have updated the documentation (README.md, docs/, demos/)
• [ ] I have updated the config schema (cli/src/config-schema.json)
• [x] I have added tests to cover my changes

[martinvonz]

@martinvonz, are you okay with this change? https://github.com/martinvonz/jj/commit/8b586b0c54ac5bd84ff5e9f5e2871252d457e27d

Yes, I don't have a better suggestion at least, and I don't want to block these PRs any more than I already have (sorry that it took me two days to even notice your question). Thank you both! I'm happy we're getting this feature soon.

[ejpcmac]

Hello, is there something I could to to help landing this? From reading the comments, it seems it was mostly good except a few nits to fix. Is just time / energy lacking? If yes I can provide some of mine.

Context: I’m just switching to Jujutsu and have an extensive use of Git worktrees and Nix Flakes, so I’m very interested in this feature, even if it’s not 100% polished.

[teto]

if there is a rebase I can help testdrive this as well. Like the previous commenter, heavy user of nix flakes and git worktrees.

[zzJinux]

I am also a heavy git worktree user and really wish it merged. Are there any blockers left, @cormacrelf ?

[yanshay]

I am also a heavy git worktree user and really wish it merged. Are there any blockers left, @cormacrelf ?

I moved from using worktrees to local clones and so far it's been working reasonably well for my needs.

[junkblocker]

I am also a heavy git worktree user and really wish it merged. Are there any blockers left, @cormacrelf ?

I moved from using worktrees to local clones and so far it's been working reasonably well for my needs.

All the non-jj tools, build automation etc. want things to recognized as a git workspace or worktree. Without that it remains a blocker for my jj adoption for work and thus for personal use too.

[ejpcmac]

Could we collectively stay focused on the matter, that is:

• either waiting silently for a reply from a maintainer or the author of the PR,
• concrete actions to try moving this forward (rebasing, testing)?

Other comments won’t add to the discussion and just add pressure where there’s no need to—it’s open-source, people are working on this on their spare time and energy.

I’ll myself try to rebase this on top of the latest master in July, when I’ll have much more time to spend on open source, if no one has done it before.

[cormacrelf]

I stopped working on it because I didn't have the energy to get through review, which is quite exhaustive. I don't mind if someone else rebases and resubmits.

[ejpcmac]

Thank you @cormacrelf for all the work already done on this subject :)

I’ll then rebase / test and proceed with the review comments in July, except if someone wants to do it before that.

[WaffleLapkin]

@ejpcmac did you end up having time for this? 👀

[ejpcmac]

@ejpcmac did you end up having time for this? 👀

TL;DR: I’m only on it since this afternoon. So far I’ve been able to setup a test repo with colocated workspaces working, with some quirks, using the code from this PR.

Done / observed so far

I’ve left my full-time job at the end of June to become a freelancer, and I initially thought I’d start working on OSS on the 1st of July. Actually I have taken a huge break and I’m back on Serious Things™ since yesterday.

Today I’ve setup a development environment and test repository to work on this PR. I am now able to create a colocated workspace using the method from the tests (i.e. creating a Git worktree, renaming it, creating a Jujutsu workspace at the same place, moving the .git file in and fixing the worktree).

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.

Also, given:

1. we have a Jujutsu / Git colocated repo,
2. we create a new Git worktree,
3. we run jj git init --colocate in this new Git worktree;

the command happily creates a new Jujutsu repo without any warning. Maybe we don’t want to fix this now, but I think we should issue a warning at some point to avoid some UX pitfall.

I haven’t looked at the code in details yet, but I’m seeing some TODOs / FIXMEs that are related to these quirks.

Next steps

Before changing anything, I’ll both look more in details at the code and rebase it on the latest main. I bet that I’ll need to open a new PR after the rebase, where we can continue the discussion.

The main question I am anticipating is: should we merge this with these git_head() quirks? Should we fix them in a follow-up, or maybe better, prior refactoring PR? I’m up to do any needed work to have a clean, unsurprising UX.

[yuja]

The main question I am anticipating is: should we merge this with these git_head() quirks? Should we fix them in a follow-up, or maybe better, prior refactoring PR? I’m up to do any needed work to have a clean, unsurprising UX.

I don't remember the details, but I think the git_head() stuff was split from this because this PR is pretty big by itself. It's probably better to work on git_head() handling separately. iirc, this PR can get smaller by removing changes that aren't strictly necessary for the minimal functional implementation, but I'm not pretty sure.

[PhilipMetzger]

The main question I am anticipating is: should we merge this with these git_head() quirks? Should we fix them in a follow-up, or maybe better, prior refactoring PR? I’m up to do any needed work to have a clean, unsurprising UX.

I don't remember the details, but I think the git_head() stuff was split from this because this PR is pretty big by itself.

Yes, that's correct see https://github.com/jj-vcs/jj/pull/4588#issuecomment-2408789687 in the original big PR.

[ejpcmac]

Hello all, little status update here.

I’ve tried to rebase the PR during the summer, but it turned out a little bit more difficult than anticipated, notably because the added code uses in some functions a parameter that has been removed. As I had zero knowledge of the code base and could not take any decision on what to do, I’ve been stuck and worked on other subjects.

I’m now taking another approach, by first getting used to the code base as a whole in term of concepts and architecture. As I prefer to think upfront and act after, I’ll also write a plan of the different steps we want to follow to enable the support of colocated workspaces. This will give us a clear view with milestones. I’ve notably seen the recent addition of jj git colocate which will likely be useful to integrate.

Would a new tracking issue on top of #4436 be a good place to discuss the plan and design? I like having a centralised place like an issue where I can edit the description to see were I’m going.

I will allocate a few hours per week on Jujutsu until the end of the year at least.

[ejpcmac]

I have created a tracking issue for this feature and its associated work: https://github.com/jj-vcs/jj/issues/8052. I will post updates in this tracking issue from now on.