Re: [PATCH 1/3] i18n.txt: camel case and monospace "i18n.commitEncoding"
From: Junio C Hamano <hidden>
Date: 2021-02-23 19:16:45
Denton Liu [off-list ref] 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 <redacted> --- Documentation/i18n.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Looking good.
quoted hunk ↗ jump to hunk
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.