Re: [PATCH/RFC 0/2] bisect per-worktree

From: Duy Nguyen <pclouds@gmail.com>
Date: Aug 3, 2015, 14:03 UTC
Message-ID: <CACsJy8B6Fg-1haJZ_xMGk8Xy0zUpeOJYgRWKbZxy_RB11JfF7g@mail.gmail.com>
In-Reply-To: <CACsJy8Cx_PTehaeQgXxGaTNRF2DUSNqbBYPQ5gQ0BYGpz6kQvQ@mail.gmail.com>

On Mon, Aug 3, 2015 at 8:02 PM, Duy Nguyen <pclouds@gmail.com> wrote:

> On Sat, Aug 1, 2015 at 10:59 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Either way, there's also the question of who should know how to find the
>> worktree-specific references--the program that wants to access them, or
>> should there be a secret invisible mapping that is done on lookup, and

After re-reading some code, I think this invisible mapping on lookup is already done for our file-based ref backend. Take resolve_ref_unsafe_1 for example, the call strbuf_git_path() may return ".git/worktrees/foo/HEAD", not ".git/HEAD", given the input ref "HEAD". So ref names are already separated from where they are stored.

>> that knows the full list of references that want to be worktree-specific
>> (for example, that in a linked worktree, "refs/bisect/*" should be
>> silently redirected to "refs/worktree/<name>/bisect/*")?

My decision to hard code these paths may turn out a bad thing (it's common_list[] in path.c). Perhaps I should let the user extend them, but we will not allow to override a small subset of paths because that may break stuff horribly.

Show 6 quoted lines

>> It's all a bit frightening, frankly.
>
> I would think all work to make pluggable backends happen should allow
> us to do this kind of transparent mapping. We can add a new file-based
> backend with just this redirection, can't we? I haven't read the
> updated refs.c though, need to do it now..

-- 
Duy