On Thu, Jul 13, 2017 at 2:32 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>>
>>> On Thu, Jul 13, 2017 at 8:01 AM, Jeff King <peff@xxxxxxxx> wrote:
>>>
>>>> builtin/branch.c | 14 +++++++-------
>>>> builtin/for-each-ref.c | 22 ++++++++++++----------
>>>> builtin/tag.c | 30 ++++++++++++++++--------------
>>>> builtin/verify-tag.c | 12 ++++++------
>>>> ref-filter.c | 22 ++++++++++++----------
>>>> ref-filter.h | 22 +++++++++++++++++-----
>>>> 6 files changed, 70 insertions(+), 52 deletions(-)
>>>
>>> The patch looks good to me. So some off-topic comments:
>>> I reviewed this patch from bottom up, i.e. I started looking at
>>> ref-filter.h, then ref-filter.c and then the rest. If only you had formatted
>>> the patches with an orderfile. ;)
>>
>> As a reviewer, for this particular patchq, I actually appreciated
>> that ref-filter.[ch] came at the end. That forced me to think.
>> ...
>> I do want to present from Doc to header to code when I am showing my
>> patch to others, so this is probably a good example that illustrates
>> that the preferred presentation order is not just personal
>> preference, but is different on occasion even for the same person.
>
> 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?"
> 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 '*',
> without which it would be cumbersome to make ref-filter.c listed
> before builtin/branch.c in a generic way.
Indeed.
