David Turner <dturner@xxxxxxxxxxxxxxxx> writes:
> Random side note: the present workspace path name component is not
> acceptable for this if alternate ref backends use a single db for
> storage across all workspaces. That's because you might create a
> workspace at foo, then manually rm -r it, and then create a new one also
> named foo. The database wouldn't know about this series of events, and
> would then have stale per-workspace refs for foo.
The users can do "Create, manuallly rm -r and recreate" dance all
they want, but the result must still honor the invariant:
For any $workspace, $workspace/.git is a "gitdir:" file that
points at one subdirectory in $GIT_COMMON_DIR/worktrees/.
The "name" I had in mind was the names of the directories in
$GIT_COMMON_DIR/worktrees/ that by definition has to be unique.
Another invariant
$GIT_COMMON_DIR/worktrees/$that_subdirectory has commondir file
that points at the $GIT_COMMON_DIR/.
must also be preserved by "Create, manuallly rm -r and recreate"
dance, but it is not important to define what the workspace ID is.
> That said, with my lmdb backend, I've been falling back to the files
> backend for per-workspace refs.
I think that is perfectly fine and within the 3-bullet design
guideline we saw earlier. Your backend is honoring the decision
made by the system as a whole what is private and what is shared,
which is the only thing that counts in the larger picture. It is up
to individual ref-backend implementations how they do so, and it is
perfectly fine that your backend takes advantage of the ref layout
by storing some stuff in lmdb storage (which I presume will live in
"common" part of the filesystem storage) and some other stuff
directly in the filesystem.
> There is one case where the refs code will probably need to directly
> call git_workspace_path: when we fix git prune to handle detached HEADs
> in workspaces. It could just set the workspace and then call git_path,
> but that is less elegant. So I think when we fix that (which should
> probably wait on for_each_worktree), we can implement Junio's proposal.
Yeah, I said *three* helper functions, but we do need the "enumerate
all workspaces" if we want to go that route, and we do need to
expose Michael's common_path() and workspace_path() to the code that
needs such an enumeration.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html