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@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html