Colocated workspaces: internal support #8252
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
All backends now have access to the workspace root if they so wish. This is not the cleanest thing ever, since the store should not need to know about the checked-out working copy on disk. However, it is very convenient if GitBackend knows it, so that it can be colocation-aware. This does the plumbing down to GitBackend::load, but does not actually use it yet. That will come later in these diffs.
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
This allows us to have a differently configured GitBackend in the newly- added workspace, i.e. one which is opened at the workspace root if we are creating a colocated workspace. This was easier than I anticipated -- we can use RepoLoader by itself to load the store from disk, and then create the new working copy commit immediately. Co-authored-by: Cormac Relf <web@cormacrelf.net> Co-authored-by: Jean-Philippe Cugnet <jean-philippe@cugnet.eu>
We want to check for colocated workspaces in the GitBackend initialization code. So it has to move to jj_lib. GitBackend also needs this in a few places, so we add a helper struct that can open and check colocation in one shot. The original is_colocated_git_workspace() will be replaced with code that inspects the git_backend. So it is left unchanged for now.
GitBackend now knows if it's colocated or not. This lays the foundation for GitBackend opening the worktree version of a git repo. Later in these diffs, we add worktree support. Then, automatically, all HEADs will be written to those worktrees instead. We won't have to add special code to re-open the git repo at the worktree (= workspace root) in a dozen places in the CLI, and then maintain discipline in selecting which repo to use when.
We will be glad to have added this when people are using worktrees and breaking them, as worktrees are a bit more sensitive to things like moving the repo around on disk.
A colocated workspace is one that also happens to have a valid .git file or directory. Currently, only the default workspace can be colocated, but we also want secondary workspaces to have this ability. To create a *secondary* colocated workspace in an existing JJ repo, we need to add a corresponding git _worktree_. JJ doesn't have the ability to create git worktrees yet. We want to test a bunch of code around colocating worktrees with a workspace, assuming we will build the functionality to actually create one in JJ itself later. So here's a helper function to do it the really hacky way with the `git` CLI, moving a .git file into place, and running `git worktree repair`.
This adds logic to the colocation-detection code to support finding a worktree with a "gitfile" as well as a full-on .git directory. Done by just trusting gix to open the workspace root/.git. It handles symlinks like the old code did, and now also handles worktrees. This means GitBackend is now opened at the worktree repo, which in turn means that colocated workspaces are somewhat independent. You can move @ in a workspace and JJ will write HEAD = @- to the git worktree in that workspace. And you can run mutating git commands in a workspace, and JJ will import the new HEAD only in that workspace. There are some new tests for what happens when you `jj git init --git-repo=...` either in or pointing at an existing worktree. I do not expect these to be common workflows, but there is new behaviour here that we need to track. There are also FIXMEs in the tests for places where we need to store one HEAD per colocated workspace in the view, as well as having independent import/export. These view changes are unwieldy and will come later. Co-authored-by: Cormac Relf <web@cormacrelf.net> Co-authored-by: Jean-Philippe Cugnet <jean-philippe@cugnet.eu>
ejpcmac
force-pushed
the
colocated-workspaces-step-1
branch
from
9b8a906 to
ae6bb85
Compare
10 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR supersedes #4644 so I can take over the work.
It includes:
It does not include any means to create a colocated workspace from the CLI. For progress on the overall feature, please see #8052.
Status
This PR is still a draft: it contains the same changes as #4644, rebased on top of the latest release, with tests updated to use the new test utils. Review comments from the previous PRs are not handled yet.
Steps
mainand ask for reviewChecklist
If applicable:
CHANGELOG.mdREADME.md,docs/,demos/)cli/src/config-schema.json)