On Sat, Aug 1, 2015 at 1:51 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> wrote: > For each worktree, we could then create a different view of the > references by splicing parts of the full reference namespace together. > This could even be based on config settings so that we don't have to > hardcode information like "refs/bisect/* is worktree-specific" deep in > the references module. Suppose we could write > > [worktree.refs] > map = refs/worktrees/*: > map = refs/bisect/*:refs/worktrees/[worktree]/refs/bisect/* Perhaps the destination should be worktrees/[worktree]/refs/bisect/*. Does it have to start with "refs/"? > which would mean (a) hide the references under refs/worktrees", and (b) > make it look as if the references under > refs/worktrees/[worktree]/refs/bisect actually appear under refs/bisect > (where "[worktree]" is replaced with the current worktree's name). By > making these settings configurable, we allow other projects to define > their own worktree-specific reference namespaces too. > > The corresponding main repo might hide "refs/worktrees/*" but leave its > refs/bisect namespace exposed in the usual place. > > "git prune" would see the whole namespace as it really is so that it can > compute reachability correctly. For multiple wortrees, first we basically remap paths in .git, relocate some to worktrees/[worktree]/ (already done), then we're going to remap config keys (submodule support, just proof of concept so far), remapping ref paths sounds like the logical next step if some under refs/ needs to be worktree-specific. I wonder if current ref namespace code could be extended to do this? -- 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