Re: [PATCH 05/15] ref-filter: abstract ref format into its own struct
- Date: Thu, 13 Jul 2017 14:32:27 -0700
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH 05/15] ref-filter: abstract ref format into its own struct
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.
Can we actually express "top-level first and then builtin/*" order
with the diff.orderfile mechanism? It's been a while since I last
looked at the orderfile matching (which was when I originally wrote
it) and I do not offhand know if we now allow wildmatch patterns and
the directory level anchoring "/*.c" like we do in .gitignore files,
without which it would be cumbersome to make ref-filter.c listed
before builtin/branch.c in a generic way.