Re: [PATCH v3 2/4] path: optimize common dir checking

[Junio C Hamano <gitster@pobox.com>]

David Turner <dturner@twopensource.com> 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.