Re: [jgit-dev] Avoiding stat calls (again)

[Christian Halstrick <christian.halstrick@xxxxxxxxx>]

Hi,

> An alternative approach is to add some sort of "compare" method to

I wanted to suggest this approach of having an explicit comparison
even before I read your mail. The fixes you suggested intend to make
idBuffer() faster. But in the use case of ANY_DIFF we are not
interested in the content IDs. We want to compare to TreeIterators
whether they currently point to the same content or not (I guess we
are only interested in content equality not in greater, lesser,...).

I see also problems in implementating this because
DirCacheIterator.compare(WorkTreeIterator) and
WorkTreeIterator.compare(DirCacheIterator) should both use an
implementation probably implemented in WorkTreeIterator  (that
implementations should be clever enough to call isModified() instead
of blindly calling idBuffer()). We could solve this by additionally
introducing a TreeIteratorComparator which implements a
compare(TreeIterator a, TreeIterator b). That compare method would be
public and the compare methods on the iterators itself would be
protected, so we enforce that the clever TreeIteratorComparator.
TeeIteratorComparator would delegate to the compare method of either
"a" or "b" depending on the types of "a" and "b". The knowledge which
comparison is better is completely hidding in the
TeeIteratorComparator and the Iteratores themselfes don't have to
care. E.g. He would take care to call the WorkingTreeIterators compare
method (which would use isModified()) if he see's thath one of the
iterators is a WorkingTreeIterator.

> AbstractTreeIterator that TreeWalk can use, so that instead of
> idEqual(int,int) we have entryEqual(int, int) that delegates down into
> that compare routine.  Then WorkingTreeIterator and DirCacheIterator
> can override the compare routine to try and special case a compare of
> those two iterator types, relying on isModified() instead of
> idBuffer().  This does get ugly implementation wise, as both iterator
> types need to override the method with identical delegation to a
> common compare routine.  If we ever grew additional iterator types,
> the permutations spread out through the various implementations quite
> quickly, making for a very bug-prone system.

-- Chris