Duy Nguyen <pclo...@gmail.com> writes: > On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano <gits...@pobox.com> wrote: > >> Do we even need to expose them as ref-like things as a part of the >> external API/UI in the first place? For end-user scripts that want >> to operate in a real or borrowing worktree, there should be no >> reason to touch this "other" repository directly. Things like "if >> one of the wortrees tries to check out a branch that is already >> checked out elsewhere, error out" policy may need to consult the >> other worktrees via $GIT_COMMON_DIR mechanism but at that level we >> have all the control without contaminating end-user facing ref >> namespace in a way main/FETCH_HEAD... do. > > No, external API/UI is just extra bonus. We need to (or should) do so > in order to handle $GIT_COMMON_DIR/HEAD exactly like how we do normal > refs.
And that is what I consider a confusion-trigger, not a nice bonus. I do not think it is particularly a good idea to contaminate end-user namespace for this kind of "peek another repository" special operation. In order to handle your "multiple worktrees manipulating the same branch" case sanely, you need to be aware of not just the real repository your worktree is borrowing from, but also _all_ the other worktrees that borrow from that same real repository, so a single "main" virtual namespace will not cut it. You will be dealing with an unbounded set of HEADs, one for each such worktree. Can't we do this by adding a "with this real repository" layer, e.g. "resolve HEAD wrt that repository", somewhat similar to how we peek into submodule namespaces? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
