Re: [PATCH 00/39] MAINTAINERS: Fix F: lines

[Markus Armbruster <armbru@redhat.com>]

Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:

> On 6/2/2026 12:00 AM, Markus Armbruster wrote:
>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>> 
>>> On 6/1/2026 3:06 AM, Markus Armbruster wrote:
>>>> Pierrick Bouvier <pierrick.bouvier@oss.qualcomm.com> writes:
>>>>
>>>>> Hi Markus,
>>>>>
>>>>> On 5/21/2026 1:04 AM, Markus Armbruster wrote:
>>>>>> Quite a few F: lines don't match any files.  The quick & dirty check
>>>>>>
>>>>>>     $ ls `sed -n 's/^F: *//p' MAINTAINERS ` >/dev/null
>>>>>>
>>>>>> finds about fifty.
>>>>>>
>>>>>> Philippe Mathieu-Daudé recently posted a few fixes:
>>>>>>
>>>>>>   MAINTAINERS: Fix docker/dockerfiles/debian-hexagon-cross.docker path
>>>>>>   MAINTAINERS: Cover debian-loongarch-cross.docker with LoongArch section
>>>>>>   MAINTAINERS: Cover debian-xtensa-cross.docker with Xtensa section
>>>>>>   MAINTAINERS: Cover debian-tricore-cross.docker with TriCore section
>>>>>>   MAINTAINERS: Cover python.docker with Python library section
>>>>>>   MAINTAINERS: Fix s390x storage key/attribute device paths
>>>>>>   MAINTAINERS: Fix tcg/s390x/ path
>>>>>>   MAINTAINERS: Correct scripts/coverity-model.c path
>>>>>>   MAINTAINERS: Fix hexagon-linux-user.mak path

[...]

>>>> I'm afraid this matches files not in git, just like my quick & dirty
>>>> one-liner.  Shouldn't we match against contents of HEAD, say output of
>>>> "git-ls-tree -r --name-only @"?
>>>>
>>>
>>> I don't think it's needed to restrict to git ls-tree. The only risk is
>>> that people have a local file they forgot (or didn't want) to add in
>>> git. It will be caught by CI that won't have such a file, so we're safe.
>>>
>>> What do you think?
>> 
>> Yes, we're safe, but the earlier we catch mistakes, the better.  Now,
>> the juice isn't always worth the squeeze.  How hard would we have to
>> squeeze here?  We could use fnmatch.filter(names, pat) to test whether
>> @pat matches anything in @names, where @names is from git-ls-tree.
>>
>
> "the earlier we catch mistakes, the better" is a good paradigm, but I
> don't think we should project that to developer machine. The only thing
> we need to keep "green" are our upstream branches.
>
> I like the simplicity of current script, only dealing with file paths,
> instead of having to do string regexp compare with git ls-files output,
> but it's just a matter of personal taste and choosing the easiest
> solution for a given problem.
>
> That said, if filtering through git ls-files is a strong requirement, I
> would be happy to implement it. Only thing that matters is that we have
> something catching mistakes.

It's what I would do, but that does *not* make it a requirement, let
alone a strong one.  I'm not the maintainer here.  You, however, are the
patch's author :)

If you want simple, consider

    $ ls `sed -n 's/^F: *//p' MAINTAINERS ` >/dev/null

[...]