Re: [PATCH/RFC 0/2] bisect per-worktree
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Aug 1, 2015, 03:59 UTC
- Message-ID
- <55BC4438.8060709@alum.mit.edu>
- In-Reply-To
- <1438387012-29229-1-git-send-email-dturner@twopensource.com>
On 08/01/2015 01:56 AM, David Turner wrote:
Show 5 quoted lines
> 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