Re: [PATCH 05/15] ref-filter: abstract ref format into its own struct

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 13, 2017, 22:45 UTC
Message-ID: <xmqqd194t0qi.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaOfcvVGUewVZMyZ7zVUcVESyzsdOBnAvG6FebuZ5HFQw@mail.gmail.com>

Stefan Beller <sbeller@google.com> writes:

Show 10 quoted lines

>> So when somebody wants to do a "from design and explanation to
>> provider to consumer", we would probably want "doc, *.h, *.c at the
>> top-level and then things inside builtin/ subdirectory" order.  Of
>> course, on the other hand, "I do not trust me not getting swayed by
>> the fact that a developer more competent than me wrote the patch"
>> reviewer would want to use the reverse order.
>
> I do not understand what you say here? Are you saying:
> "I can be tricked easier when the order is top-down,
> specifically when the more competent developer tries to?"

I am not worried about the case in which patch author actively "tries to" deceive. It is more like "I am more likely to fail to spot mistakes the patch author failed to spot himself", when I start with reasoning, service provider implementations and then service consumer. When I am forced to think the problem myself before seeing the answer and then compare the result with patch author's answer, I am more likely to find such a mistake.

Show 6 quoted lines

>> Can we actually express "top-level first and then builtin/*" order
>> with the diff.orderfile mechanism?
>
> By reading the code, I think we snap to the first match. And matching
> is done via the wildmatch.{c,h}, that claims it has special-case '/' matching,
> and '**' **  work differently than '*',

I took a brief look at diffcore-order.c; I do not think "/*.c" would match only top-level .c files like gitignore files would.