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