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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.

> 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.