Re: [PATCH 2/2] ref-filter: support filtering of operational refs

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2024, 17:59 UTC
Message-ID: <xmqqedey9u32.fsf@gitster.g>
In-Reply-To: <ZZWbMekL2URby0qV@tanuki>

Patrick Steinhardt <ps@pks.im> writes:

Show 13 quoted lines

>> 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.