> Here we intend to feed the dequote an ISO-Latin encoded string. Our decoder > will first try to decode it as UTF-8, which should fail, then we try to decode it > as the platform default (Linear A, Hieroglyphs, MacRoman or something not > known to living mankind). A problem is that Git *forces* us to guess the encoding, > and in some situations you'd need human intelligence to figure it out. Software > with a little more hindsight recognize this and declare UTF-8 to be the one > and only encoding. JGit always encodes things as UTF-8 for this reason, but > we cannot trust the input. These test cases are supposed to prove that we > can guess things correctly at least some of the time.. Using "platform > default" may be the wrong thing if it does not match what a C Git user on > this platform would encounter. > I got your reply exaclty as I found the same thing :-). I'm not sure that this is the common cause of all test failures, but it is for testGetText_DiffCc :- When it parses the first string in extractFileLines, it passes to RawParseUtils.decode which, as you outlined, does a "Try UTF-8, Try caller suggestion, try Charset.defaultCharset(), then finally back out to ISO-8859-1. On most platforms, this is Try UTF-8 (fail), caller suggestion (also UTF-8, skip), try default (UTF-8, skip) - finally parse ISO-8859-1. On the mac, this is Try UTF-8 (fail), caller suggestion (UTF-8, skip), try default (MacRoman) --> succeed. I'm less clear on what the right way to fix it is (or if it's just the tests that need to somehow force the system file.encoding? -- 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
