Patrick Steinhardt <ps@xxxxxx> writes: >> I think we should tighten things up over time. First by teaching >> the ref backend that anything that is not a pseudoref, HEAD or a >> proper ref (one item of whose definition is "lives under refs/ >> hierarchy) should not resolve_ref() successfully. That should >> correctly fail things like >> >> $ git rev-parse worktrees/$name/bisect/bad >> $ git update-ref foo/bar HEAD > ... > Yeah, agreed, that's something we should do. I do wonder whether this > will break existing usecases, but in any case I'd rather consider it an > accident that it is possible to write (and read) such refs in the first > place. Unfortunately, the worktrees/$name/refs/bisect/bad and its friends are documented in "git worktree" and the refs.c layer is aware of the "main-worktree/" and "worktrees/" hierarchy, so while I still think it is a good long-term direction to make it impossible to create random refs like "foo/bar" and "resf/heads/master" via the commands like "git update-ref", we cannot limit ourselves only to "refs/" hierarchy.
