From: Michael Haggerty Date: Sat, 01 Aug 2015 03:59:52 GMT Subject: Re: [PATCH/RFC 0/2] bisect per-worktree 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: > 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//" 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//bisect/*")? It's all a bit frightening, frankly. Michael -- Michael Haggerty mhagger@alum.mit.edu