Re: [PATCH] doc: centrally document various ways spell `true` and `false`

From: Taylor Blau <me@ttaylorr.com>
Date: Mar 12, 2025, 22:17 UTC
Message-ID: <Z9IH6G7BnM0blOmH@nand.local>
In-Reply-To: <xmqqy0ycz9dk.fsf@gitster.g>

On Tue, Feb 11, 2025 at 09:20:07AM -0800, Junio C Hamano wrote:

>  Cc'ed Taylor, as the author of fb0dc3ba (builtin/config.c: support
>  `--type=<type>` as preferred alias for `--<type>`, 2018-04-18) this
>  patch butchers.

Wow, this is a blast from the past. I think this was one of my first contributions to Git, and indeed:

    $ git log --oneline --author=Taylor.Blau --until=2018-04-18 | wc -l
    9

Show 17 quoted lines

>  Documentation/git-config.txt     | 4 +++-
>  Documentation/git.txt            | 5 +++--
>  Documentation/pretty-formats.txt | 8 ++++----
>  3 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git c/Documentation/git-config.txt w/Documentation/git-config.txt
> index 3e420177c1..76042581ec 100644
> --- c/Documentation/git-config.txt
> +++ w/Documentation/git-config.txt
> @@ -213,7 +213,9 @@ See also <<FILES>>.
>  +
>  Valid `<type>`'s include:
>  +
> -- 'bool': canonicalize values as either "true" or "false".
> +- 'bool': canonicalize values `true`, `yes`,`on`, and positive
> +  numbers as "true", and values `false`, `no`, `off` and `0` as
> +  "false".

I agree with the rest of the patch, but is this true (no pun intended ;-))? I thought that we might canonicalize "yes" to "yes" if the value we are asking about is already something other than a literal "true" or "false", but I don't think we do:

    $ git.compile -c foo.bar=yes config --type=bool foo.bar
    true

So I do think that it is worth saying "you can spell 'true' as 'yes', '1', ..." in the documentation, but I don't think that it is correct that we'll canonicalize "yes" to "true" in the case described here.

Sorry that this took me so long to respond to. I think I must have missed it when you wrote it and I only noticed it today while cleaning up old emails.

Thanks, Taylor