Re: [JGIT PATCH] Fix AbstractTreeIterator path comparion betwen 'a' and 'a/b'
- From
Tor Arne Vestbø <torarnv@gmail.com>
- Date
- Feb 3, 2009, 17:10 UTC
- Message-ID
- <49887A86.2040602@gmail.com>
- In-Reply-To
- <20090203170337.GX26880@spearce.org>
Shawn O. Pearce wrote:
Show 18 quoted lines
> 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.
Show 6 quoted lines
> 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