[JGIT PATCH v2] Fixed QuotedStringGitPathStyleTest.testDequote_OctalAll test that generated incorrect UTF-8 escape sequences

The test was failing on the system that use a encoding different
from ISO-8859-1. The reason was that invalid UTF-8 bytes were
generated for codepoints greater than U+7F, and in this case
the method RawParseUtils.decodeNoFallback falls backs to the
default system encoding.

Signed-off-by: Constantine Plotnikov <redacted>
---

The bug was causing failure for the maven build on the windows
environment that uses Cp1251 as a system encoding. However the test
worked from Eclipse until I have specified jvm option
-Dfile.ecoding=Cp1251, in the test case started to fail in Eclipse as
well.

 .../jgit/util/QuotedStringGitPathStyleTest.java    |   21 ++++++++++++++-----
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/QuotedStringGitPathStyleTest.java

b/org.spearce.jgit.test/tst/org/spearce/jgit/util/QuotedStringGitPathStyleTest.java
index 54fbd31..7d29f21 100644

--- a/org.spearce.jgit.test/tst/org/spearce/jgit/util/QuotedStringGitPathStyleTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/QuotedStringGitPathStyleTest.java

@@ -127,13 +127,22 @@ public void testDequote_NamedEscapes() {
 	}

 	public void testDequote_OctalAll() {
-		for (int i = 0; i < 256; i++) {
-			String s = Integer.toOctalString(i);
-			while (s.length() < 3) {
-				s = "0" + s;
-			}
-			assertDequote("" + (char) i, "\\" + s);
+		for (int i = 0; i < 127; i++) {
+			assertDequote("" + (char) i, octalEscape(i));
 		}
+		for (int i = 128; i < 256; i++) {
+			int f = 0xC0 | (i >> 6);
+			int s = 0x80 | (i & 0x3f);
+			assertDequote("" + (char) i, octalEscape(f)+octalEscape(s));
+		}
+	}
+
+	private String octalEscape(int i) {
+		String s = Integer.toOctalString(i);
+		while (s.length() < 3) {
+			s = "0" + s;
+		}
+		return "\\"+s;
 	}

 	public void testQuote_OctalAll() {

-- 
1.6.1.2

Constantine Plotnikov [off-list ref] wrote:

The test was failing on the system that use a encoding different
from ISO-8859-1. The reason was that invalid UTF-8 bytes were
generated for codepoints greater than U+7F, and in this case
the method RawParseUtils.decodeNoFallback falls backs to the
default system encoding.

Signed-off-by: Constantine Plotnikov <redacted>

Thanks.

The bug was causing failure for the maven build on the windows
environment that uses Cp1251 as a system encoding. However the test
worked from Eclipse until I have specified jvm option
-Dfile.ecoding=Cp1251, in the test case started to fail in Eclipse as
well.

-- 
Shawn.