From: Shawn O. Pearce <spearce@spearce.org>
Date: Mon, 23 Jun 2008 00:27:07 GMT
Subject: Re: [PATCH 1/2] Create a fnmatch-style pattern TreeFilter
Message-ID: <20080623002707.GK11793@spearce.org>
In-Reply-To: <1214177145-18963-1-git-send-email-robin.rosenberg@dewire.com>

Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> +
> +package org.spearce.jgit.revwalk.filter;

This should be treewalk.filter, its a filter for tree entries.

> + * This class implements a TreeeFilter that uses the wildcard style pattern

fyi, minooooor typo on TreeFilter.

> +public class WildCardTreeFilter extends TreeFilter {
...
> +	@Override
> +	public boolean include(TreeWalk walker) throws MissingObjectException,
> +			IncorrectObjectTypeException, IOException {
> +		matcher.reset();
> +		matcher.append(walker.getPathString());
> +		if (matcher.isMatch())
> +			return true;
> +		return false;
> +	}

Hmm. 

It isn't as efficient as it could be.  Obtaining the string of
the path is somewhat costly as we have to convert from the byte[]
to a char[] and then wrap that into a String, just to check the
pattern again.  Its more accurate to convert to the string, but
it is a lot slower.

But I'm wondering about what happens when the TreeWalk is considering
a subtree path name.  Does the matcher still match the pattern?  By
that I mean lets say the pattern was:

	src/xdiff/*.c

In this case the include method is first called with the path "src";
if it returns false the TreeWalk won't recurse into the subtree and
thus you'll never get to consider "src/xdiff" or "src/xdiff/foo.c".

-- 
Shawn.