From: "Shawn O. Pearce" <spearce@spearce.org>
To: Robin Rosenberg <robin.rosenberg@dewire.com>
Cc: git@vger.kernel.org, Marek Zawirski <marek.zawirski@gmail.com>,
Florian Koeberle <florianskarten@web.de>
Subject: Re: [PATCH 1/2] Create a fnmatch-style pattern TreeFilter
Date: Sun, 22 Jun 2008 20:27:07 -0400 [thread overview]
Message-ID: <20080623002707.GK11793@spearce.org> (raw)
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.
next prev parent reply other threads:[~2008-06-23 0:28 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-22 23:25 [PATCH 1/2] Create a fnmatch-style pattern TreeFilter Robin Rosenberg
2008-06-22 23:25 ` [PATCH 2/2] LsTree: Enable pattern matching in LsTree Robin Rosenberg
2008-06-23 0:27 ` Shawn O. Pearce [this message]
2008-06-23 17:32 ` [PATCH 1/2] Create a fnmatch-style pattern TreeFilter Florian Köberle
2008-06-23 17:43 ` [[JGIT PATCH]] Implementation of a copy constructor for FileNameMatcher Florian Köberle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080623002707.GK11793@spearce.org \
--to=spearce@spearce.org \
--cc=florianskarten@web.de \
--cc=git@vger.kernel.org \
--cc=marek.zawirski@gmail.com \
--cc=robin.rosenberg@dewire.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.