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

From: David Turner <[email-masked]>
Date: Fri, 14 Aug 2015 16:54:20 -0400

On Fri, 2015-08-14 at 13:27 -0700, Junio C Hamano wrote:
> David Turner <[email-masked]> 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.

My worry was that workspace would get deleted and
recreated without the refs db finding out.  Then the refs db would
retain per-workspace references from the deleted version of the
worskace.  That is, these names are unique at any given time, but not
across time.

My idea was just to have `git workspace add` create per-workspace
"workspace_id" file with a long random number in it. The id would be
$that_subdirectory/$random_number; we would know to split it at / and
double-check that the workspace id is still current before assuming that
our refs data was valid for the workspace.  

Alternately, git workspace add could inform the refs backend that a
workspace is being added, which would solve the problem in a different
way.

But given my refs lmdb backend design, I can actually ignore this for
now, so that's what I'm going to do.