Re: [JGIT PATCH] Fix AbstractTreeIterator path comparion betwen 'a' and 'a/b'

Shawn O. Pearce wrote:

OK, so I think this is a valid test case, and as it turns out,
it passes with the library unmodified:

--8<--
+	public void testPathCompare() throws Exception {
+		assertTrue(new FakeTreeIterator("a", FileMode.TREE).pathCompare(
+				new FakeTreeIterator("a", FileMode.TREE)) == 0);
+
+		assertTrue(new FakeTreeIterator("a", FileMode.REGULAR_FILE).pathCompare(
+				new FakeTreeIterator("a", FileMode.REGULAR_FILE)) == 0);
+
+		assertTrue(new FakeTreeIterator("a", FileMode.REGULAR_FILE).pathCompare(
+				new FakeTreeIterator("a", FileMode.TREE)) < 0);
+
+		assertTrue(new FakeTreeIterator("a", FileMode.TREE).pathCompare(
+				new FakeTreeIterator("a", FileMode.REGULAR_FILE)) > 0);
+	}
----

Okey, I'll post a new patch with just those test cases, no changes to
the pathCompare, so we at least have those tests.

Which means whatever problem you have been seeing in the decorator
code is different than what we were originally thinking.  Perhaps you
are trying to use the tree iterator APIs in a way that they aren't
meant to be used (like passing in full paths where only a path name
component is expected?), or there is something else lurking that
we don't understand.

Ahh, I see. My patch was based on the assumption that 'a/b' was a valid
comparison, since I was seeing similar comparisons in live code. But as
you say, that's probably due to how I use the iterators. I will go back
and investigate how I ended up with 'a/b' paths in the first place.

Thanks :)

Tor Arne