From: Jeff King <peff@peff.net>
To: Denton Liu <liu.denton@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Junio C Hamano <gitster@pobox.com>,
Andrew White <andrew.white@audinate.com>
Subject: Re: [PATCH] Use OPT_CALLBACK and OPT_CALLBACK_F
Date: Tue, 28 Apr 2020 04:45:43 -0400 [thread overview]
Message-ID: <20200428084543.GC2381876@coredump.intra.peff.net> (raw)
In-Reply-To: <d6d35a21a5bb1077eea4dd49f5716bece9e015de.1588062647.git.liu.denton@gmail.com>
On Tue, Apr 28, 2020 at 04:36:28AM -0400, Denton Liu wrote:
> In the codebase, there are many options which use OPTION_CALLBACK in a
> plain ol' struct definition. However, we have the OPT_CALLBACK and
> OPT_CALLBACK_F macros which are meant to abstract these plain struct
> definitions away. These macros are useful as they semantically signal to
> developers that these are just normal callback option with nothing fancy
> happening.
I think this is worth doing. It's a little easier to read, and sets a
better example anyone copying the code.
> Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or
> OPT_CALLBACK_F where applicable. The heavy lifting was done using the
> following (disgusting) shell script:
> [...]
I'll admit I gave only a quick read through the results. I think between
your script, the manual look-over for style, and the fact that the
compiler would catch any minor syntactic screwups, I'm not likely to
see any new errors.
> I contemplated breaking this down into file-sized patches but I don't
> think it really makes sense in this case since it's the same change
> which is being made in each file and, imo, it wouldn't really ease
> reviewer burden since the same number of changes are being reviewed.
As a reviewer I much prefer one big patch like this, since these are all
the same case: changing style X to style Y. I'd want patches broken out
if there were other case (say, the parameters for some version needed
fixed up as you were converting). But I don't see that here.
-Peff
next prev parent reply other threads:[~2020-04-28 8:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-27 1:31 Bug v2.23.0: command help for 'git push --recurse-submodules' is incorrect Andrew White
2020-04-27 6:44 ` [PATCH] push: unset PARSE_OPT_OPTARG for --recurse-submodules Denton Liu
2020-04-27 12:02 ` Jeff King
2020-04-27 18:54 ` Junio C Hamano
2020-04-28 8:36 ` [PATCH] Use OPT_CALLBACK and OPT_CALLBACK_F Denton Liu
2020-04-28 8:45 ` Jeff King [this message]
2020-04-28 17:34 ` Junio C Hamano
2020-04-28 17:51 ` [PATCH] push: unset PARSE_OPT_OPTARG for --recurse-submodules Junio C Hamano
2020-04-28 22:59 ` Denton Liu
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=20200428084543.GC2381876@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=andrew.white@audinate.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=liu.denton@gmail.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).