On Wed, Jan 03, 2024 at 09:59:13AM -0800, Junio C Hamano wrote: > 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. Ah, I first wanted to point this out, but then noticed that you didn't include the "refs/" prefix in "worktrees/$name/bisect/bad" and thought this was intentional. But yes, per-worktree refs need to stay supported, weird as they may be. Patrick
Attachment:
signature.asc
Description: PGP signature
