Subject: Re: [PATCH 4/5] config.c: add a "tristate" helper

From: Junio C Hamano <[email-masked]>
Date: Fri, 09 Apr 2021 15:11:10 -0700

Jeff King <[email-masked]> writes:

> It seems like it would be more convenient if you could pass it a bool
> value to turn the "auto" into. E.g., if you could do:
>
>   b = git_parse_maybe_tristate(value, 1); /* default to "1" */
>   if (b < 0)
>           do_error();
>   if (b)
>           do_true(); /* true, or maybe "auto" */
>   else
>           do_false();
>
> I dunno. That would probably be hard to represent via "git config
> --type". And some callers probably do care about "auto" versus "true".

It would work well for codepaths where computing the default value
is cheap (or even possible).

I think the point of using "auto" is to delay the decision as late
as possible.  E.g. in-core parsed config and attribute may still
want to stay "auto", until we actually get our hands on the blob
contents to see if it is binary, until we know how heavily loaded
the system is, until we know isatty(1), etc.  Some are cheap to
compute in advance, some are expensive and impossible until we meet
the data.

So I still think the canonical use pattern for the "auto" thing is

	is_frotz = git_parse_bool_or_auto(value);

	... arbitrary number of things can happen here
	... the above may even be done in a git_config()
	... callback, and is_frotz may not even be used.

	if (is_frotz == AUTO)
		is_frotz = auto_detect_frotz();

	if (is_frotz)
		...; /* do the frotz thing */
	else
		...; /* do the non-frotz thing */

> It also feels funny calling this "tristate". Aren't there other
> tristates we could have besides "auto"? The command-line option is
> bool-or-auto, which is descriptive. Should this use a similar name?

I like that bool-or-auto name very much.