From: Heba Waly <heba.waly@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Heba Waly via GitGitGadget <gitgitgadget@gmail.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v4 2/3] advice: revamp advise API
Date: Tue, 25 Feb 2020 12:49:57 +1300 [thread overview]
Message-ID: <CACg5j25XQLC1bYxm4244UQddL5AVENg-0XwJQFvLpdQ-n1hVqg@mail.gmail.com> (raw)
In-Reply-To: <xmqqftezod3n.fsf@gitster-ct.c.googlers.com>
On Tue, Feb 25, 2020 at 11:05 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "Heba Waly via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > -static void vadvise(const char *advice, va_list params)
> > +static const char *advice_config_keys[] = {
> > + [FETCH_SHOW_FORCED_UPDATES] = "fetchShowForcedUpdates",
> > + [PUSH_UPDATE_REJECTED] = "pushUpdateRejected",
> > + /* make this an alias for backward compatibility */
> > + [PUSH_UPDATE_REJECTED_ALIAS] = "pushNonFastForward",
> > +...
> > + [CHECKOUT_AMBIGUOUS_REMOTE_BRANCH_NAME] = "checkoutAmbiguousRemoteBranchName",
> > + [NESTED_TAG] = "nestedTag",
> > + [SUBMODULE_ALTERNATE_ERROR_STRATEGY_DIE] = "submoduleAlternateErrorStrategyDie"
> > +};
>
> Terminate the last entry of the array with a trailing comma ',', so
> that the next person who adds one new advise key to the table at the
> end has to just add only one line without changing any existing lines.
>
Sure, thank you for the explanation, that makes sense.
> As you are using the designated initializers for this array, we are
> free to order the lines in any way that makes most sense to us and
> do not have to order the lines in numerical order. In what order
> are these lines sorted right now? I am tempted to suggest that we
> should sort alphabetically on the values, i.e. run the contents of
> the table through "LC_ALL=C sort -k2,2 -t=".
>
Currently it's sorted in the same order that was originally used for
advice_config[] and the global variables, which I assume is the order
in which every config variable was added to the code. Sorting
alphabetically will be neater of course.
> > +
> > +static const char turn_off_instructions[] =
> > +N_("\n"
> > + "Disable this message with \"git config %s false\"");
> > +
> > +static void vadvise(const char *advice, va_list params,
> > + int display_instructions, char *key)
>
> It may be just me, but I feel uneasy when I see va_list in the
> middle of the parameter list. As it is a mechanism to allow us
> handle "the remainder of the arguments", it logically makes more
> sense to have it as the last parameter.
>
I don't mind it either way, so yeah no problem, I'll change that.
> > {
> > struct strbuf buf = STRBUF_INIT;
> > const char *cp, *np;
> >
> > strbuf_vaddf(&buf, advice, params);
> >
> > + if(display_instructions)
> > + strbuf_addf(&buf, turn_off_instructions, key);
>
> Style. We always have one SP between a syntactic keyword like "if"
> and open parenthesis.
Noted.
>
> > +
> > for (cp = buf.buf; *cp; cp = np) {
> > np = strchrnul(cp, '\n');
> > fprintf(stderr, _("%shint: %.*s%s\n"),
> > @@ -119,8 +161,42 @@ void advise(const char *advice, ...)
> > {
> > va_list params;
> > va_start(params, advice);
> > - vadvise(advice, params);
> > + vadvise(advice, params, 0, "");
> > + va_end(params);
> > +}
> > +
> > +static int get_config_value(enum advice_type type)
> > +{
> > + int value = 1;
> > + char *key = xstrfmt("%s.%s", "advice", advice_config_keys[type]);
>
> Have a blank line between the decl and the first statement, i.e. here.
>
Right, I missed this one.
> > + git_config_get_bool(key, &value);
> > + free(key);
> > + return value;
> > +}
> > +
> > +int advice_enabled(enum advice_type type)
> > +{
> > + switch(type) {
>
> Style.
Noted.
>
> > + case PUSH_UPDATE_REJECTED:
> > + return get_config_value(PUSH_UPDATE_REJECTED) &&
> > + get_config_value(PUSH_UPDATE_REJECTED_ALIAS);
> > + default:
> > + return get_config_value(type);
> > + }
> > +}
> > +
> > +void advise_if_enabled(enum advice_type type, const char *advice, ...)
> > +{
> > + char *key = xstrfmt("%s.%s", "advice", advice_config_keys[type]);
> > + va_list params;
> > +
> > + if(!advice_enabled(type))
>
> Stile.
Takes time changing the style I've been using for years, sorry.
>
> > + return;
> > +
> > + va_start(params, advice);
> > + vadvise(advice, params, 1, key);
> > va_end(params);
> > + free(key);
> > }
> >
> > int git_default_advice_config(const char *var, const char *value)
> > @@ -159,8 +235,8 @@ void list_config_advices(struct string_list *list, const char *prefix)
> > {
> > int i;
> >
> > - for (i = 0; i < ARRAY_SIZE(advice_config); i++)
> > - list_config_item(list, prefix, advice_config[i].name);
> > + for (i = 0; i < ARRAY_SIZE(advice_config_keys); i++)
> > + list_config_item(list, prefix, advice_config_keys[i]);
> > }
> >
> > int error_resolve_conflict(const char *me)
> > diff --git a/advice.h b/advice.h
> > index b706780614d..61a7ee82827 100644
> > --- a/advice.h
> > +++ b/advice.h
> > @@ -32,9 +32,61 @@ extern int advice_checkout_ambiguous_remote_branch_name;
> > extern int advice_nested_tag;
> > extern int advice_submodule_alternate_error_strategy_die;
> >
> > +/**
> > + To add a new advice, you need to:
> > + - Define an advice_type.
> > + - Add a new entry to advice_config_keys list.
> > + - Add the new config variable to Documentation/config/advice.txt.
> > + - Call advise_if_enabled to print your advice.
> > + */
>
> /*
> * Our multi-line comments should look
> * more like this (multiple style violations
> * in this patch).
> */
>
Got it.
> > +enum advice_type {
> > + FETCH_SHOW_FORCED_UPDATES = 0,
> > + PUSH_UPDATE_REJECTED = 1,
> > + PUSH_UPDATE_REJECTED_ALIAS = 2,
> > + PUSH_NON_FF_CURRENT = 3,
>
> Do we need to spell out the values, or is it sufficient to let the
> compiler automatically count up? Does any code depend on the exact
> numeric value of the advice type, or at least at the source code
> level the only thing we care about them is that they are distinct?
>
> I'd really want to get rid of these exact value assignments---they
> are source of unnecessary conflicts when two or more topics want to
> add new advice types of their own.
>
Yes, we can get rid of them.
> I also suggest that these are sorted alphabetically.
As we'll get rid of the value assignments, so sorting alphabetically
should not introduce problems when adding new advice types, will do.
> > + ...
> > + SUBMODULE_ALTERNATE_ERROR_STRATEGY_DIE = 28,
> > +};
>
> > +++ b/t/t0018-advice.sh
> > @@ -0,0 +1,28 @@
> > +#!/bin/sh
> > +
> > +test_description='Test advise_if_enabled functionality'
> > +
> > +. ./test-lib.sh
> > +
> > +cat > expected <<EOF
> > +hint: This is a piece of advice
> > +hint: Disable this message with "git config advice.nestedTag false"
> > +EOF
> > +test_expect_success 'advise should be printed when config variable is unset' '
> > + test-tool advise "This is a piece of advice" 2>actual &&
> > + test_i18ncmp expected actual
> > +'
>
> - Prepare the expected output inside test_expect_success block that
> uses it.
>
> - There should be no SP between a redirection operator and the
> filename.
>
> - Here-doc that does not use parameter expansion should use a
> quoted EOF marker.
>
> - The file that gets compared with "actual" is by convention called
> "expect", not "expected".
>
> i.e.
>
> test_expect_success 'advise should be printed when config variable is unset' '
> cat >expect <<-\EOF &&
> hint: ...
> hint: ...
> EOF
> test-tool advise "This is a piece of advice" 2>actual &&
> test_i18ncmp expected actual
> '
Noted.
Will send an updated version soon.
Thank you,
Heba
next prev parent reply other threads:[~2020-02-24 23:50 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-10 5:04 [PATCH] advice: refactor advise API Heba Waly via GitGitGadget
2020-02-10 14:38 ` Derrick Stolee
2020-02-10 19:30 ` Junio C Hamano
2020-02-10 19:42 ` Taylor Blau
2020-02-10 22:29 ` Emily Shaffer
2020-02-11 0:08 ` Heba Waly
2020-02-12 20:57 ` Taylor Blau
2020-02-10 23:56 ` Heba Waly
2020-02-11 2:39 ` Derrick Stolee
2020-02-10 20:37 ` Jeff King
2020-02-10 22:55 ` Emily Shaffer
2020-02-11 2:35 ` Heba Waly
2020-02-11 19:49 ` Jeff King
2020-02-11 19:51 ` Jeff King
2020-02-11 2:20 ` Heba Waly
2020-02-10 22:46 ` Junio C Hamano
2020-02-11 2:01 ` Heba Waly
2020-02-11 6:08 ` Junio C Hamano
2020-02-16 21:39 ` [PATCH v2 0/2] [RFC][Outreachy] " Heba Waly via GitGitGadget
2020-02-16 21:39 ` [PATCH v2 1/2] " Heba Waly via GitGitGadget
2020-02-17 3:28 ` Junio C Hamano
2020-02-17 10:03 ` Heba Waly
2020-02-19 9:59 ` Heba Waly
2020-02-16 21:39 ` [PATCH v2 2/2] advice: extract vadvise() from advise() Heba Waly via GitGitGadget
2020-02-17 0:09 ` [PATCH v2 0/2] [RFC][Outreachy] advice: refactor advise API Junio C Hamano
2020-02-19 20:33 ` [PATCH v3 0/2] [Outreachy] advice: revamp " Heba Waly via GitGitGadget
2020-02-19 20:34 ` [PATCH v3 1/2] " Heba Waly via GitGitGadget
2020-02-20 1:37 ` Emily Shaffer
2020-02-21 0:31 ` Heba Waly
2020-02-19 20:34 ` [PATCH v3 2/2] advice: extract vadvise() from advise() Heba Waly via GitGitGadget
2020-02-20 1:42 ` Emily Shaffer
2020-02-21 0:34 ` Heba Waly
2020-02-24 15:13 ` [PATCH v4 0/3] [Outreachy] advice: revamp advise API Heba Waly via GitGitGadget
2020-02-24 15:13 ` [PATCH v4 1/3] advice: extract vadvise() from advise() Heba Waly via GitGitGadget
2020-02-24 22:04 ` Emily Shaffer
2020-02-24 15:13 ` [PATCH v4 2/3] advice: revamp advise API Heba Waly via GitGitGadget
2020-02-24 22:05 ` Junio C Hamano
2020-02-24 22:11 ` Eric Sunshine
2020-02-24 23:51 ` Heba Waly
2020-02-24 23:49 ` Heba Waly [this message]
2020-02-24 23:45 ` Emily Shaffer
2020-02-24 15:13 ` [PATCH v4 3/3] tag: use new advice API to check visibility Heba Waly via GitGitGadget
2020-02-24 22:07 ` Junio C Hamano
2020-02-24 23:46 ` Emily Shaffer
2020-02-25 10:55 ` [PATCH v5 0/3] [Outreachy] advice: revamp advise API Heba Waly via GitGitGadget
2020-02-25 10:55 ` [PATCH v5 1/3] advice: extract vadvise() from advise() Heba Waly via GitGitGadget
2020-02-25 10:55 ` [PATCH v5 2/3] advice: revamp advise API Heba Waly via GitGitGadget
2020-02-25 17:40 ` Junio C Hamano
2020-02-25 19:56 ` Emily Shaffer
2020-02-25 20:09 ` Junio C Hamano
2020-02-25 20:35 ` Junio C Hamano
2020-02-25 21:19 ` Heba Waly
2020-02-25 22:02 ` Junio C Hamano
2020-02-26 0:37 ` Heba Waly
2020-02-26 3:03 ` Junio C Hamano
2020-02-26 20:28 ` Heba Waly
2020-02-26 20:44 ` Junio C Hamano
2020-02-26 21:48 ` Jonathan Tan
2020-02-25 10:55 ` [PATCH v5 3/3] tag: use new advice API to check visibility Heba Waly via GitGitGadget
2020-02-25 17:48 ` Junio C Hamano
2020-02-27 4:35 ` [PATCH v6 0/4] [Outreachy] advice: revamp advise API Heba Waly via GitGitGadget
2020-02-27 4:35 ` [PATCH v6 1/4] advice: extract vadvise() from advise() Heba Waly via GitGitGadget
2020-02-27 4:35 ` [PATCH v6 2/4] advice: change "setupStreamFailure" to "setUpstreamFailure" Heba Waly via GitGitGadget
2020-02-27 17:38 ` Junio C Hamano
2020-02-27 4:35 ` [PATCH v6 3/4] advice: revamp advise API Heba Waly via GitGitGadget
2020-02-27 20:49 ` Junio C Hamano
2020-02-29 0:58 ` Heba Waly
2020-02-27 4:35 ` [PATCH v6 4/4] tag: use new advice API to check visibility Heba Waly via GitGitGadget
2020-03-02 20:01 ` [PATCH v7 0/4] [Outreachy] advice: revamp advise API Heba Waly via GitGitGadget
2020-03-02 20:01 ` [PATCH v7 1/4] advice: extract vadvise() from advise() Heba Waly via GitGitGadget
2020-03-02 20:01 ` [PATCH v7 2/4] advice: change "setupStreamFailure" to "setUpstreamFailure" Heba Waly via GitGitGadget
2020-03-02 20:01 ` [PATCH v7 3/4] advice: revamp advise API Heba Waly via GitGitGadget
2020-03-02 21:03 ` Junio C Hamano
2020-03-03 14:15 ` Junio C Hamano
2020-03-04 3:22 ` Heba Waly
2020-03-02 20:02 ` [PATCH v7 4/4] tag: use new advice API to check visibility Heba Waly via GitGitGadget
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=CACg5j25XQLC1bYxm4244UQddL5AVENg-0XwJQFvLpdQ-n1hVqg@mail.gmail.com \
--to=heba.waly@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.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).