On Mon, Aug 3, 2015 at 8:02 PM, Duy Nguyen <pclouds@xxxxxxxxx> wrote: > On Sat, Aug 1, 2015 at 10:59 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> 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. >> 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 -- 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