Jeff King <peff@xxxxxxxx> writes: > On Wed, Apr 04, 2012 at 12:37:25PM +0200, Erik Faye-Lund wrote: > ... >> The problem is that for some helpers you need to know the encoding in >> order to have a user-interface show the data. This goes both for OSX >> and Windows. If you mess up the encoding, in the helper, then you'll >> mess up the entries in the OS'es key-managers. While this might not be >> a problem in practice for US-English users, we've seen for Git for >> Windows that e.g. some Asians are really unhappy with their username >> becoming some completely incomprehensible string. > > How are they inputting their username? If they are seeing garbage, then > surely it is coming to git in some encoding that is different than what > the password manager expects. Then we give it to a helper, which hands > it to system storage, which assumes that what we give it is utf-8. So > the error there seems to me to be the layer between the helper and the > system storage, where the string is converted from "a stream of bytes" > to "a utf-8 encoded string". > > So why is this a credential helper protocol problem, and not an > implementation issue for the specific helper? How does git find out the > encoding? Presumably by checking $LANG, or whatever system-specific > locale information there is. Can't the helper do the same thing? FWIW, this matches exactly my reaction. If a helper on a specific system somehow *knows* the user means to give UTF-8, uses system UI that interacts with the user and gives UTF-16 back, and uses system store that takes UCS-2, it is entirely sensible for the helper to convert between these encodings internally and use UTF-8 when interacting with credential-helper API which only expects "stream of bytes". But that is just a specific implementation detail of the helper. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html