From: Junio C Hamano <gitster@pobox•com>
To: David Turner <dturner@twopensource•com>
Cc: Michael Haggerty <mhagger@alum•mit.edu>,
git@vger•kernel.org, chriscool@tuxfamily•org, pclouds@gmail•com
Subject: Re: [PATCH v3 2/4] path: optimize common dir checking
Date: Fri, 14 Aug 2015 13:27:17 -0700 [thread overview]
Message-ID: <xmqq1tf5ipju.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <1439582644.8855.89.camel@twopensource.com> (David Turner's message of "Fri, 14 Aug 2015 16:04:04 -0400")
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.
next prev parent reply other threads:[~2015-08-14 20:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 21:57 [PATCH v3 1/4] refs: clean up common_list David Turner
2015-08-12 21:57 ` [PATCH v3 2/4] path: optimize common dir checking David Turner
2015-08-12 22:48 ` Junio C Hamano
2015-08-13 9:05 ` Michael Haggerty
2015-08-14 17:04 ` Junio C Hamano
2015-08-14 20:04 ` David Turner
2015-08-14 20:27 ` Junio C Hamano [this message]
2015-08-14 20:54 ` David Turner
2015-08-15 18:20 ` Michael Haggerty
2015-08-15 18:12 ` Michael Haggerty
2015-08-17 15:55 ` Junio C Hamano
2015-08-15 7:59 ` Duy Nguyen
2015-08-16 5:04 ` David Turner
2015-08-16 12:20 ` Duy Nguyen
2015-08-12 21:57 ` [PATCH v3 3/4] refs: make refs/worktree/* per-worktree David Turner
2015-08-13 17:15 ` Eric Sunshine
2015-08-13 17:41 ` David Turner
2015-08-13 20:16 ` Michael Haggerty
2015-08-13 20:32 ` David Turner
2015-08-14 8:18 ` Michael Haggerty
2015-08-14 17:10 ` Junio C Hamano
2015-08-15 8:04 ` Duy Nguyen
2015-08-12 21:57 ` [PATCH v3 4/4] bisect: make bisection refs per-worktree David Turner
2015-08-15 7:44 ` [PATCH v3 1/4] refs: clean up common_list Duy Nguyen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1tf5ipju.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=chriscool@tuxfamily$(echo .)org \
--cc=dturner@twopensource$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mhagger@alum$(echo .)mit.edu \
--cc=pclouds@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox