Denton Liu <liu.denton@xxxxxxxxx> 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@xxxxxxxxx>
> ---
> 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.
