John Cai <johncai86@xxxxxxxxx> writes:
>>> 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...
