Re: [PATCH 0/3] revision: refactor ref_excludes to ref_visibility

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 23, 2023, 20:57 UTC
Message-ID: <xmqqo7l5aoc1.fsf@gitster.g>
In-Reply-To: <941CCF5B-1FE6-46BE-9ED7-77C11E943E2E@gmail.com>

John Cai <johncai86@gmail.com> writes:

Show 19 quoted lines

>>> After reading this description, I am not sure why you can't "include" a
>>> reference that would otherwise be excluded by passing the rules:
>>>
>>>   - refs/heads/exclude/*
>>>   - !refs/heads/exclude/but/include/me
>>>
>>> (where the '!' prefix in the last rule is what brings back the included
>>> reference).
>>>
>>> But let's read on and see if there is something that I'm missing.
>>
>> Having read this series in detail, I am puzzled. I don't think that
>> there is any limitation of the existing reference hiding rules that
>> wouldn't permit what you're trying to do by adding the list of
>> references you want to include at the end of the exclude list, so long
>> as they are each prefixed with the magic "!" sentinel.
>
> To be honest, I had no idea "!" would have this effect--so thanks for bringing
> it to my attention.

FWIW, "--exclude=!" gets zero hits in t/ directory.

ref_excluded() merely calls wildmatch() like so:

        int ref_excluded(const struct ref_exclusions *exclusions, const char *path)
        {
                const char *stripped_path = strip_namespace(path);
                struct string_list_item *item;

                for_each_string_list_item(item, &exclusions->excluded_refs) {
                        if (!wildmatch(item->string, path, 0))
                                return 1;
                }

                if (ref_is_hidden(stripped_path, path, &exclusions->hidden_refs))
                        return 1;

                return 0;
        }

so I do not know what to think about it. This is called from inside callback of things like "log --exclude=A --exclude=B ... --all" when we are trying to add all refs in response to "--all", and it appears to me that the first match would already determine the ref's fate without even looking at the later patterns (prefixed with bang '!' or not). Taylor, am I looking at a wrong code?

Puzzled...