POC for GitBackend opening worktrees #4801
Closed
Conversation
This file contains 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
A colocated workspace is one that also happens to have a valid .git file or directory. To create a colocated workspace in an existing JJ repo, we need to add a corresponding git _worktree_. JJ doesn't have the ability to create colocated workspaces 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`.
Previously, only the default workspace could be colocated. This adds logic to the colocation-detection code to support finding a worktree with a "gitfile" as well as a full-on .git directory. 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.
…ix], backend] Needed in the next diff.
…_head This makes colocated workspaces 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. Previously, any imports and exports were against the git backing repo, which is sometimes colocated with the default workspace. So colocated workspaces were not independent, they all read and wrote from the same HEAD in the backing repo.
…t worktree Now that colocated workspaces exist, it is necessary to distinguish the two kinds of git repository `jj` might open. There's the git backend (which is either a bare repository or a colocated one) and the worktrees for all the colocated workspaces. Both of these are a `gix/git2::Repository`, the difference is just which path you opened. So you have to distinguish them with names. This rename mostly serves as an opportunity to review at least some of the usages of explicit usage of the git backend repo.
cormacrelf
force-pushed
the
workspace-colocate-minimal
branch
from
1f362de to
ba0823a
Compare
We want to check for colocated workspaces in the GitBackend initialization code. So it has to move to jj_lib.
This does the plumbing but does not actually use it.
- Add MaybeColocatedGitRepo helper, to open the workspace root if
colocation is detected
- Save any warning generated on the GitBackend via
`GitRepoColocationType::NotColocated { warning: Some(...) }`
- try reopening as colocated during GitBackend::init_external, in addition to during ::load
This allows us to have a differently configured GitBackend in the newly- added workspace, i.e. one which was 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.
No longer necessary. GitBackend has already opened the correct repo. So we may simply get the store's git backend and read the HEAD from it. We do NOT remove the repository parameter from git::reset_head, because: - it has had this param since before the worktree code came around - it still uses `git2::Repository` and judging from a token attempt, converting this code is a lot of work. But, at least in theory, git::reset_head can just use the `gix::Repository` on the GitBackend.
cormacrelf
force-pushed
the
git-backend-worktree
branch
from
d13acad to
a512e2d
Compare
cormacrelf
force-pushed
the
workspace-colocate-minimal
branch
4 times, most recently
from
3750492 to
3d83cdb
Compare
|
Closed because this is all in #4644 now. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Just to illustrate what #4644 could do differently. See discussion there.
Checklist
If applicable:
CHANGELOG.md