From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.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 14:32:27 -0700 [thread overview]
Message-ID: <xmqqmv88t444.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <xmqqlgnsulco.fsf@gitster.mtv.corp.google.com> (Junio C. Hamano's message of "Thu, 13 Jul 2017 13:34:47 -0700")
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.
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.
next prev parent reply other threads:[~2017-07-13 21:32 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 [this message]
2017-07-13 22:01 ` Stefan Beller
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=xmqqmv88t444.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sbeller@google.com \
/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).