git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
David Turner <dturner@twopensource.com>
Date
Aug 14, 2015, 20:54 UTC
Message-ID
<1439585660.8855.102.camel@twopensource.com>
In-Reply-To
<xmqq1tf5ipju.fsf@gitster.dls.corp.google.com>
On Fri, 2015-08-14 at 13:27 -0700, Junio C Hamano wrote:
Show 25 quoted lines
> 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.

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.

Previous: Junio C HamanoNext: Michael Haggerty
Message 8 of 24 in “refs: clean up common_list”
  1. 1/4 refs: clean up common_listDavid Turner, Aug 12, 2015
  2. 2/4 path: optimize common dir checkingDavid Turner, Aug 12, 2015
  3. Junio C HamanoAug 12, 2015
  4. Michael HaggertyAug 13, 2015
  5. Junio C HamanoAug 14, 2015
  6. David TurnerAug 14, 2015
  7. Junio C HamanoAug 14, 2015
  8. David TurnerAug 14, 2015
  9. Michael HaggertyAug 15, 2015
  10. Michael HaggertyAug 15, 2015
  11. Junio C HamanoAug 17, 2015
  12. Duy NguyenAug 15, 2015
  13. David TurnerAug 16, 2015
  14. Duy NguyenAug 16, 2015
  15. 3/4 refs: make refs/worktree/* per-worktreeDavid Turner, Aug 12, 2015
  16. Eric SunshineAug 13, 2015
  17. David TurnerAug 13, 2015
  18. Michael HaggertyAug 13, 2015
  19. David TurnerAug 13, 2015
  20. Michael HaggertyAug 14, 2015
  21. Junio C HamanoAug 14, 2015
  22. Duy NguyenAug 15, 2015
  23. 4/4 bisect: make bisection refs per-worktreeDavid Turner, Aug 12, 2015
  24. Duy NguyenAug 15, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.