> On 07 Mar 2018, at 00:07, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Lars Schneider <larsxschneider@xxxxxxxxx> writes: >> >>>> Also "UTF16" or other spelling >>>> the platform may support but this code fails to recognise will go >>>> unchecked. >>> >>> That is true. However, I would assume all iconv implementations use the >>> same encoding names for UTF encodings, no? That means UTF16 would never be >>> valid. Would you agree? >> >> After seeing "UTF16" and others in "iconv -l | grep -i utf" output, >> I am not sure what you mean by "Would you agree?" People can say in >> their .gitattributes file that this path is in "UTF16" without dash >> and that is what will be fed to this code, no? > > FWIW, "iconv -f utf8 -t utf16" seems not to complain, so I am > reasonably sure that people expect downcased ones to work as well. Sure! That's why I normalized it to upper case: https://public-inbox.org/git/CAPig+cQE0pKs-AMvh4GndyCXBMnx=70jPpDM6K4jJTe-74FecQ@xxxxxxxxxxxxxx/ After thinking about it I wonder if we should barf on "utf16" without dash. Your Linux iconv would handle this correctly. My macOS iconv would not. That means the repo would checkout correctly on your machine but not on mine. What do you think? - Lars
