Re: [PATCH 1/3] i18n.txt: camel case and monospace "i18n.commitEncoding"

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 23, 2021, 19:15 UTC
Message-ID: <xmqq7dmy389l.fsf@gitster.g>
In-Reply-To: <cc48b125166a241ef5f24138fd161223ab35e361.1614062288.git.liu.denton@gmail.com>

Denton Liu <liu.denton@gmail.com> writes:

Show 11 quoted lines

> In 95791be750 (doc: camelCase the i18n config variables to improve
> readability, 2017-07-17), the other i18n config variables were
> camel cased. However, this one instance was missed.
>
> Camel case and monospace "i18n.commitEncoding" so that it matches the
> surrounding text.
>
> Signed-off-by: Denton Liu <liu.denton@gmail.com>
> ---
>  Documentation/i18n.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Looking good.

Show 13 quoted lines

> diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
> index 7e36e5b55b..6c6baeeeb7 100644
> --- a/Documentation/i18n.txt
> +++ b/Documentation/i18n.txt
> @@ -38,7 +38,7 @@ mind.
>    a warning if the commit log message given to it does not look
>    like a valid UTF-8 string, unless you explicitly say your
>    project uses a legacy encoding.  The way to say this is to
> -  have i18n.commitencoding in `.git/config` file, like this:
> +  have `i18n.commitEncoding` in `.git/config` file, like this:
>  +
>  ------------
>  [i18n]

Thanks, but whenever you noticed an issue like "Ah, here we used an incorrect spelling i18n.commitencoding", please make it a habit to see if we did exactly the same mistake elsewhere (you have been working with Git long enough to know how cheap such a check is):

    $ git grep -F -e i18n.commitencoding -- \
         Documentation/ ':!Documentation/RelNotes/'

and you would have found three other instances.

This obviously does not have to be part of this miniseries, but I wonder if we should have a list of all the configuration variables in one place that we can use to record the canonical spelling of these variables. As

$ git grep -h -E -i \
	-e '^[a-z][-a-z0-9]*\.[a-z][-a-z0-9]*::' \
	-e '^[a-z][-a-z0-9]*\.(\*|<?[a-z][-a-z0-9]*>?)\.(\*|<?[a-z][-a-z0-9]*>?)::' \
	Documentation/config

gives many hits with camelCased names, it might be a good place to start.

Pretending that the above gives a good "canonical list" (it does not yet, if you look at the hits), I got curious how far we can go.

Massaging the output from the above into config-variables.lst

$ ... above command ... |
  sed -e 's/::$//' |
  sort -u >config-variables.lst

and then to extract use of these tokens in the main part of the documentation like this:

$ git grep -h -o -i -F -f config-variables.lst -- \
  Documentation/ ':!Documentation/RelNotes/' |
  sort -u >config-usage.lst

gives us something we can compare with the "canonical" usage list.

$ comm -3 config-usage.lst config-variables.lst blame.blankboundary core.excludesfile core.filemode core.gitproxy core.ignorestat core.logallrefupdates core.repositoryformatversion core.trustCtime http.sslverify http.sslversion i18n.commitencoding push.pushoption remote.<name>.partialCloneFilter remote.pushdefault repack.UseDeltaBaseOffset sendemail.aliasesfile showbranch.default transfer.hiderefs uploadArchive.allowUnreachable

Some of them may be false hits, some may be showing that the copy in Documentation/config/ are spelled in all lowercase, but the majority of the hits above seem to be genuine errors similar to what you fixed in your patch.

Thanks.