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

["Tor Arne Vestbø" <torarnv@gmail.com>]

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