git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: David Turner <dturner@twopensource.com>,
	Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, chriscool@tuxfamily.org, pclouds@gmail.com
Subject: Re: [PATCH v3 2/4] path: optimize common dir checking
Date: Sat, 15 Aug 2015 20:20:11 +0200	[thread overview]
Message-ID: <55CF82DB.8010204@alum.mit.edu> (raw)
In-Reply-To: <1439582644.8855.89.camel@twopensource.com>

On 08/14/2015 10:04 PM, David Turner wrote:
> On Fri, 2015-08-14 at 10:04 -0700, Junio C Hamano wrote:
>> [...]
>> So I think we should have *three* functions:
>>
>>  - git_workspace_name(void) returns some name that uniquely
>>    identifies the current workspace among the workspaces linked to
>>    the same repository.
> 
> 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 reference backend should clearly have functions that are called on
the creation and destruction of a workspace. In these functions the
backend could initialize / clean up any reference-related resources
associated with that workspace.

These functions can be empty for the filesystem backend.

> That said, with my lmdb backend, I've been falling back to the files
> backend for per-workspace refs.  This also means I don't have to worry
> about expiring per-workspace refs when a workspace is removed. 
> 
> I could change this, but IIRC, there are a fair number of things that
> care about the existence of a file called HEAD, so the fallback was
> easier.  (That is, the other way was a giant hassle).

OK, so the functions can be empty for the lmdb backend, too :-)

> [...]
> For this patch series, I don't think we need to change anything [...]
> Implementing
> Junio's proposal would not affect this series; it would just be an
> additional patch on top (or beforehand).

OK.

> [...]

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu

  parent reply	other threads:[~2015-08-15 18:20 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
2015-08-15 18:20         ` Michael Haggerty [this message]
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=55CF82DB.8010204@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=chriscool@tuxfamily.org \
    --cc=dturner@twopensource.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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).