Dnia piątek, 27 sierpnia 2021 19:03:56 CEST Junio C Hamano pisze: > > + The encoding must be a system encoding supported by iconv(1), > > + otherwise this option will be ignored. > > + POSIX character maps used by iconv(1p) are not supported. > > This paragraph is a bit hard to grok. > > I think it is saying that the "-f frommap -t tomap" form in [*1*] > that can use arbitrary character set description file is not > supported, but "-f fromcode -t tocode" form, which also is what > iconv_open() takes [*2*], is supported. Am I reading it correctly? Yes > > Is there an easier-to-read way to explain the distinction to our > average reader? It is not our job to explain what POSIX character maps are. The takeaway is they are unsupported; if you do not know what they are, why should you bother? > > What I am getting at is this. Imagine average users who need to see > their commits recoded to iso-8859-2. They see "git log" has > "--encoding=<encoding>" option, read the above paragraph and wonder > if they are on the supported side or unsupported side of the above > paragraph. I want to make it easy for them to stop wondering. > > For that purpose, "iconv(1) vs iconv(1p)" would not help them very > much, especially considering that not all Git users are UNIX users > (they probably do not even know what (1) and (1p) means). I am sorry, as a UNIX user I have no idea what iconv, being part of the GNU C library, means and how it works on a non-UNIX system that does not contain one. If you know, could you enlighten us please? > I think our end-user facing manual pages tend to avoid the latter. > We do use "shall" in the RFC2119/BCP14 sense on the technical side > of our documentation where we give requirements to the third-party > implementations so that they can interoperate with us, but this is > not such a description. > > Thanks. I shall revert it after we have come to an agreement about the POSIX stuff. BR, Chris
