Re: [PATCH 1/2] Create a fnmatch-style pattern TreeFilter

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jun 23, 2008, 00:27 UTC
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 {

...

Show 9 quoted lines

> +	@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.