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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 14, 2015, 20:27 UTC
Message-ID: <xmqq1tf5ipju.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1439582644.8855.89.camel@twopensource.com>

David Turner <dturner@twopensource.com> writes:

Show 6 quoted lines

> 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.

Show 5 quoted lines

> 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.