From: David Turner <dturner@twopensource.com>
To: Junio C Hamano <gitster@pobox.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 16:54:20 -0400 [thread overview]
Message-ID: <1439585660.8855.102.camel@twopensource.com> (raw)
In-Reply-To: <xmqq1tf5ipju.fsf@gitster.dls.corp.google.com>
On Fri, 2015-08-14 at 13:27 -0700, Junio C Hamano wrote:
> 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.
next prev parent reply other threads:[~2015-08-14 20:54 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
2015-08-14 20:54 ` David Turner [this message]
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=1439585660.8855.102.camel@twopensource.com \
--to=dturner@twopensource.com \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
--cc=pclouds@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).