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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 08/01/2015 01:56 AM, David Turner wrote:
> This is RFC because I'm not sure why show-ref only works on refs/ (and
> whether it should learn to look in worktree-refs/).  I'm also not sure
> whether there are other changes I should make to refs.c to handle
> per-worktree refs; I basically did the simplest thing I could think of
> to start with.

It seems to me that adding a new top-level "worktree-refs" directory is
pretty traumatic. Lots of people and tools will have made the assumption
that all "normal" references live under "refs/".

Each worktree has a name, right? What if worktree-specific refs were
stored under "refs/worktree/<name>/" or something? This would require
the name to be a valid reference name component, but I think that is a
prudent idea anyway.

Of course that doesn't answer the question: where should the refs for
the main repository go? I suppose either in the current place, or maybe
the main repository should have a name too (e.g. "main") and its
references should be stored under "refs/worktree/main/".

These worktree-specific refs should presumably be deleted automatically
when the worktree is deleted.

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
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/*")?

It's all a bit frightening, frankly.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu