Pierrick Bouvier <[email protected]> writes:
> On 6/2/2026 12:00 AM, Markus Armbruster wrote:
>> Pierrick Bouvier <[email protected]> writes:
>>
>>> On 6/1/2026 3:06 AM, Markus Armbruster wrote:
>>>> Pierrick Bouvier <[email protected]> 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
[...]
