All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, "Lin Sun" <lin.sun@zoom.us>,
	"Đoàn Trần Công Danh" <congdanhqx@gmail.com>,
	"David Aguilar" <davvid@gmail.com>
Subject: Re: [PATCH 4/5] config.c: add a "tristate" helper
Date: Thu, 08 Apr 2021 11:33:13 -0700	[thread overview]
Message-ID: <xmqqa6q8tymu.fsf@gitster.g> (raw)
In-Reply-To: <patch-4.6-222e91e11b-20210408T133125Z-avarab@gmail.com> ("Ævar	Arnfjörð Bjarmason"'s message of "Thu, 8 Apr 2021 15:34:28 +0200")

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> Add "tristate" functions to go along with the "bool" functions and
> migrate the common pattern of checking if something is "bool" or
> "auto" in various places over to the new functions.
>
> We also have e.g. "repo_config_get_bool" and
> "config_error_nonbool". I'm not adding corresponding "tristate"
> functions as they're not needed by anything, but we could add those in
> the future if they are.
>
> I'm not migrating over "core.abbrev" parsing as part of this
> change. When "core.abbrev" was made optionally boolean in
> a9ecaa06a7 (core.abbrev=no disables abbreviations, 2020-09-01) the
> "die if empty" code added in g48d5014dd4 (config.abbrev: document the
> new default that auto-scales, 2016-11-01) wasn't adjusted. It thus
> behaves unlike all other "maybe bool" config variables.
>
> I have a planned series to start adding some tests for "core.abbrev",
> but AFAICT there's not even a test for "core.abbrev=true", and I'd
> like to focus on thing that have no behavior change here, so let's
> leave it for now.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>  builtin/log.c  | 13 +++++++------
>  compat/mingw.c |  6 +++---
>  config.c       | 16 ++++++++++++++++
>  config.h       | 12 ++++++++++++
>  http.c         |  5 +++--
>  userdiff.c     |  6 ++----
>  6 files changed, 43 insertions(+), 15 deletions(-)

> diff --git a/config.c b/config.c
> index fc28dbd97c..74d2b2c0df 100644
> --- a/config.c
> +++ b/config.c
> @@ -1257,6 +1257,14 @@ int git_parse_maybe_bool(const char *value)
>  	return -1;
>  }
>  
> +int git_parse_maybe_tristate(const char *value)
> +{
> +	int v = git_parse_maybe_bool(value);
> +	if (v < 0 && !strcasecmp(value, "auto"))
> +		return 2;
> +	return v;
> +}

This is not parse_mayb_bool_text(), so "1" and "-1" written in the
configuration file are "true", "0" is "false", like the "bool" case.

I wonder if written without an unnecessary extra variable, i.e.

	if (value && !strcasecmp(value, "auto"))
		return 2;
	return git_parse_maybe_bool(value);

is easier to follow, though, as it is quite clear that it is mostly
the same as maybe_bool and the only difference is when "auto" is
given.

> +int git_config_tristate(const char *name, const char *value)
> +{
> +	int v = git_parse_maybe_tristate(value);
> +	if (v < 0)
> +		die(_("bad tristate config value '%s' for '%s'"), value, name);
> +	return v;
> +}

OK.

> diff --git a/config.h b/config.h
> index 19a9adbaa9..c5129e4392 100644
> --- a/config.h
> +++ b/config.h
> @@ -197,6 +197,12 @@ int git_parse_ulong(const char *, unsigned long *);
>   */
>  int git_parse_maybe_bool(const char *);
>  
> +/**
> + * Same as `git_parse_maybe_bool`, except that "auto" is recognized and
> + * will return "2".
> + */
> +int git_parse_maybe_tristate(const char *);

A false being 0 and a true being 1 is understandable for readers
without symbolic constant, but "2" deserves to have a symbolic
constant, doesn't it?

> @@ -226,6 +232,12 @@ int git_config_bool_or_int(const char *, const char *, int *);
>   */
>  int git_config_bool(const char *, const char *);
>  
> +/**
> + * Like git_config_bool() except "auto" is also recognized and will
> + * return "2"
> + */
> +int git_config_tristate(const char *, const char *);

Likewise.

Thanks.

  reply	other threads:[~2021-04-08 18:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-08 13:34 [PATCH 0/5] config: support --type=bool-or-auto for "tristate" parsing Ævar Arnfjörð Bjarmason
2021-04-08 13:34 ` [PATCH 1/5] config.c: add a comment about why value=NULL is true Ævar Arnfjörð Bjarmason
2021-04-08 18:10   ` Junio C Hamano
2021-04-08 13:34 ` [PATCH 2/5] config tests: test for --bool-or-str Ævar Arnfjörð Bjarmason
2021-04-08 18:21   ` Junio C Hamano
2021-04-08 23:11     ` Ævar Arnfjörð Bjarmason
2021-04-08 13:34 ` [PATCH 3/5] git-config: document --bool-or-str and --type=bool-or-str Ævar Arnfjörð Bjarmason
2021-04-08 18:22   ` Junio C Hamano
2021-04-08 13:34 ` [PATCH 4/5] config.c: add a "tristate" helper Ævar Arnfjörð Bjarmason
2021-04-08 18:33   ` Junio C Hamano [this message]
2021-04-08 23:23     ` Ævar Arnfjörð Bjarmason
2021-04-08 23:51       ` Junio C Hamano
2021-04-09  1:33         ` Ævar Arnfjörð Bjarmason
2021-04-09 12:53           ` Junio C Hamano
2021-04-08 23:54       ` Junio C Hamano
2021-04-09 20:05     ` Jeff King
2021-04-09 22:11       ` Junio C Hamano
2021-04-10  1:23         ` Jeff King
2021-04-10  1:43           ` Junio C Hamano
2021-04-08 13:34 ` [PATCH 5/5] config: add --type=bool-or-auto switch Ævar Arnfjörð Bjarmason
2021-04-08 18:36   ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqa6q8tymu.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=congdanhqx@gmail.com \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=lin.sun@zoom.us \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.