From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>, "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH 05/15] ref-filter: abstract ref format into its own struct
Date: Thu, 13 Jul 2017 15:01:19 -0700 [thread overview]
Message-ID: <CAGZ79kaOfcvVGUewVZMyZ7zVUcVESyzsdOBnAvG6FebuZ5HFQw@mail.gmail.com> (raw)
In-Reply-To: <xmqqmv88t444.fsf@gitster.mtv.corp.google.com>
On Thu, Jul 13, 2017 at 2:32 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Stefan Beller <sbeller@google.com> writes:
>>
>>> On Thu, Jul 13, 2017 at 8:01 AM, Jeff King <peff@peff.net> 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.
next prev parent reply other threads:[~2017-07-13 22:01 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-13 14:55 [PATCH 0/15] making user-format colors conditional on config/tty Jeff King
2017-07-13 14:56 ` [PATCH 01/15] check return value of verify_ref_format() Jeff King
2017-07-13 14:56 ` [PATCH 02/15] docs/for-each-ref: update pointer to color syntax Jeff King
2017-07-13 20:15 ` Junio C Hamano
2017-07-13 14:58 ` [PATCH 03/15] t: use test_decode_color rather than literal ANSI codes Jeff King
2017-07-13 18:40 ` Stefan Beller
2017-07-13 18:45 ` Jeff King
2017-07-13 19:27 ` Junio C Hamano
2017-07-14 11:50 ` Jeff King
2017-07-13 20:18 ` Junio C Hamano
2017-07-13 14:58 ` [PATCH 04/15] ref-filter: simplify automatic color reset Jeff King
2017-07-13 15:01 ` [PATCH 05/15] ref-filter: abstract ref format into its own struct Jeff King
2017-07-13 18:51 ` Stefan Beller
2017-07-13 20:34 ` Junio C Hamano
2017-07-13 21:32 ` Junio C Hamano
2017-07-13 22:01 ` Stefan Beller [this message]
2017-07-13 22:45 ` Junio C Hamano
2017-07-13 15:02 ` [PATCH 06/15] ref-filter: move need_color_reset_at_eol into ref_format Jeff King
2017-07-13 20:36 ` Junio C Hamano
2017-07-13 15:02 ` [PATCH 07/15] ref-filter: provide a function for parsing sort options Jeff King
2017-07-13 15:02 ` [PATCH 08/15] ref-filter: make parse_ref_filter_atom a private function Jeff King
2017-07-13 15:02 ` [PATCH 09/15] ref-filter: factor out the parsing of sorting atoms Jeff King
2017-07-13 15:06 ` [PATCH 10/15] ref-filter: pass ref_format struct to atom parsers Jeff King
2017-07-13 15:07 ` [PATCH 11/15] color: check color.ui in git_default_config() Jeff King
2017-07-13 15:07 ` [PATCH 12/15] for-each-ref: load config earlier Jeff King
2017-07-13 15:07 ` [PATCH 13/15] rev-list: pass diffopt->use_colors through to pretty-print Jeff King
2017-07-13 15:08 ` [PATCH 14/15] pretty: respect color settings for %C placeholders Jeff King
2017-07-13 15:09 ` [PATCH 15/15] ref-filter: consult want_color() before emitting colors Jeff King
2017-07-13 19:14 ` [PATCH 0/15] making user-format colors conditional on config/tty Stefan Beller
2017-07-13 20:46 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGZ79kaOfcvVGUewVZMyZ7zVUcVESyzsdOBnAvG6FebuZ5HFQw@mail.gmail.com \
--to=sbeller@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).