Jiang Xin <worldhello.net@xxxxxxxxx> writes: > I know there are two config variables. i18n.commitEncoding will insert > a "encoding XX" line to the commit object, while i18n.logOutputEncoding > will set the default output encoding. But this implementation seems like > a workaround. > > * Tree objects do not have such implementation, so multibyte characters > can not be used as filenames. Even outside i18n/l10n context, projects that want to be usable by wide population avoid filesystem-unsafe characters, which are not limited to just multi-byte. Even though Git started on Linux, we do not have a file whose name contains '\' or HT, which would have made it impossible to check out on DOS. It's just "common sense" or "common courtesy". In any case, I do not expect we would need to have po/國語.po in git-l10n repository, so this is a non issue in the context of this discussion thread. > * Commit object without "encoding" instruction will be used as it is. So > people under the same non-utf8 locale may not notice that they > have not set the proper i18n.commitEncoding, until one day they > need accross platform development. That is why we have l10n coordinator who can vet such mistakes crawling into our system, isn't it? > I think save commit object, tree object, packed-refs in UTF-8 is > a better implementation. It is one of the better conventions to encourage. It is entirely a different matter to forbid a closed local user community from adopting GB, Big5, EUC or whatever character encoding as the encoding of their choice, and using it throughout their project for pathnames, blob payloads and log messages. -- 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