Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
Felipe Contreras felipe.contre...@gmail.com writes: On Fri, Aug 30, 2013 at 6:55 PM, Junio C Hamano gits...@pobox.com wrote: People often find git log --branches etc. that includes _all_ branches is cumbersome to use when they want to grab most but except some. The same applies to --tags, --all and --glob. This idea looks very familiar, from the wording of this commit message it seems you came with the idea out of nowhere. Did you? As the comment after three-dash quotes, the inspiration came from this suggestion: It may be a good idea to step back a bit and think of this topic as a way to enhance the --branches option and its friends with only the inclusive wildcard semantics. which is not anything new. It takes from J6t's To unclutter 'git branch' output, I rename work-in-progress branches to begin with wip/, ready-to-merge branches do not carry this prefix. To inspect unmerged work of the latter kind of branches I would like to type... what? But the thing is, that is nothing new, either. Pretty much ever since we added --branches --tags and later --glob, (1) traversing from almost all but minus some branches, and (2) stopping traversal at almost all but minus some branches were what people sometimes wanted to have (which is pretty much what the first paragraph of the proposed commit message says) using negative glob. Looking the phrase in the list archive finds for example $gmane/159770 from 2010, but I would not be surprised if you find older message wishing the same. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
Johannes Sixt j...@kdbg.org writes:
Am 31.08.2013 01:55, schrieb Junio C Hamano:
People often find git log --branches etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some. The same applies to --tags, --all and --glob.
Teach the revision machinery to remember patterns, and then upon the
next such a globbing option, exclude those that match the pattern.
With this, I can view only my integration branches (e.g. maint,
master, etc.) without topic branches, which are named after two
letters from primary authors' names, slash and topic name.
git rev-list --no-walk --exclude=??/* --branches |
git name-rev --refs refs/heads/* --stdin
This one shows things reachable from local and remote branches that
have not been merged to the integration branches.
git log --remotes --branches --not --exclude=??/* --branches
It may be a bit rough around the edges, in that the pattern to give
the exclude option depends on what globbing option follows. In
these examples, the pattern ??/* is used, not refs/heads/??/*,
because the globbing option that follows the --exclude=pattern
is --branches. As each use of globbing option resets previously
set --exclude, this may not be such a bad thing, though.
I argued --except should trump everything earlier, but the case
involving --not
--branches --except maint --not master
to mean the same as
--branches --except maint master
just does not make sense.
I'll have to mull the above two over to firmly grasp what you mean
by 'except' trumping 'not' before deciding if you are agreeing or
disagreeing with the approach of taking it as a taming wildcard
issue...
An alternative would be that --not would divide the command line
arguments into ranges within which one --except would subtract
subsequent refs from earlier globbing arguments in the same range.
That's not simpler to explain than your current proposal.
So I like the relative simplicity of this approach. Here is a bit of
documentation.
Oh, thanks for helping. An example or two may also help, and using
your original I have branches and wip/ situation would be good.
git log --exclude='wip/*' --branches::
Show history of local branches whose names do not
match pattern `wip/*`.
git log --remotes --not --exclude='wip/*' --branches::
Show history of other people's work that are not
merged to local branches whose names do not match
pattern `wip/*`.
or something like that, perhaps?
--- 8 ---
Subject: [PATCH] document --exclude option
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Documentation/rev-list-options.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 5bdfb42..650c252 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -174,6 +174,21 @@ parents) and `--max-parents=-1` (negative numbers denote
no upper limit).
is automatically prepended if missing. If pattern lacks '?',
'{asterisk}',
or '[', '/{asterisk}' at the end is implied.
+--exclude=glob-pattern::
+
+ Do not include refs matching 'glob-pattern' that the next `--all`,
+ `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
+ consider. Repetitions of this option accumulate exclusion patterns
+ up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
+ `--glob` option (other options or arguments do not clear
+ accumlated patterns).
++
+The patterns given should not begin with `refs/heads`, `refs/tags`, or
+`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
+restrictively, and they must begin with `refs/` when applied to `--glob`
+or `--all`. If a trailing '/{asterisk}' is intended, it must be given
+explicitly.
+
--ignore-missing::
Upon seeing an invalid object name in the input, pretend as if
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
Am 03.09.2013 18:03, schrieb Junio C Hamano: Johannes Sixt j...@kdbg.org writes: So I like the relative simplicity of this approach. Here is a bit of documentation. Oh, thanks for helping. An example or two may also help, and using your original I have branches and wip/ situation would be good. git log --exclude='wip/*' --branches:: Show history of local branches whose names do not match pattern `wip/*`. git log --remotes --not --exclude='wip/*' --branches:: Show history of other people's work that are not merged to local branches whose names do not match pattern `wip/*`. or something like that, perhaps? Agreed and noted. The new option must also be integrated in rev-parse. That will take a bit more work. I'll pick up the topic when I find the time to do so. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
On Tue, Sep 3, 2013 at 10:45 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Fri, Aug 30, 2013 at 6:55 PM, Junio C Hamano gits...@pobox.com wrote: People often find git log --branches etc. that includes _all_ branches is cumbersome to use when they want to grab most but except some. The same applies to --tags, --all and --glob. This idea looks very familiar, from the wording of this commit message it seems you came with the idea out of nowhere. Did you? As the comment after three-dash quotes, the inspiration came from this suggestion: It may be a good idea to step back a bit and think of this topic as a way to enhance the --branches option and its friends with only the inclusive wildcard semantics. which is not anything new. It takes from J6t's To unclutter 'git branch' output, I rename work-in-progress branches to begin with wip/, ready-to-merge branches do not carry this prefix. To inspect unmerged work of the latter kind of branches I would like to type... what? Yeah, and where did that come from? But the thing is, that is nothing new, either. Pretty much ever since we added --branches --tags and later --glob, (1) traversing from almost all but minus some branches, and (2) stopping traversal at almost all but minus some branches were what people sometimes wanted to have (which is pretty much what the first paragraph of the proposed commit message says) using negative glob. Looking the phrase in the list archive finds for example $gmane/159770 from 2010, but I would not be surprised if you find older message wishing the same. It is very peculiar that your patch suddenly appeared after I sent a patch for --except, and nobody has sent a similar patch, which is not what you would expect if this was nothing new. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
Am 31.08.2013 01:55, schrieb Junio C Hamano:
People often find git log --branches etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some. The same applies to --tags, --all and --glob.
Teach the revision machinery to remember patterns, and then upon the
next such a globbing option, exclude those that match the pattern.
With this, I can view only my integration branches (e.g. maint,
master, etc.) without topic branches, which are named after two
letters from primary authors' names, slash and topic name.
git rev-list --no-walk --exclude=??/* --branches |
git name-rev --refs refs/heads/* --stdin
This one shows things reachable from local and remote branches that
have not been merged to the integration branches.
git log --remotes --branches --not --exclude=??/* --branches
It may be a bit rough around the edges, in that the pattern to give
the exclude option depends on what globbing option follows. In
these examples, the pattern ??/* is used, not refs/heads/??/*,
because the globbing option that follows the --exclude=pattern
is --branches. As each use of globbing option resets previously
set --exclude, this may not be such a bad thing, though.
I argued --except should trump everything earlier, but the case
involving --not
--branches --except maint --not master
to mean the same as
--branches --except maint master
just does not make sense.
An alternative would be that --not would divide the command line
arguments into ranges within which one --except would subtract
subsequent refs from earlier globbing arguments in the same range.
That's not simpler to explain than your current proposal.
So I like the relative simplicity of this approach. Here is a bit of
documentation.
--- 8 ---
Subject: [PATCH] document --exclude option
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Documentation/rev-list-options.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 5bdfb42..650c252 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -174,6 +174,21 @@ parents) and `--max-parents=-1` (negative numbers denote
no upper limit).
is automatically prepended if missing. If pattern lacks '?',
'{asterisk}',
or '[', '/{asterisk}' at the end is implied.
+--exclude=glob-pattern::
+
+ Do not include refs matching 'glob-pattern' that the next `--all`,
+ `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
+ consider. Repetitions of this option accumulate exclusion patterns
+ up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
+ `--glob` option (other options or arguments do not clear
+ accumlated patterns).
++
+The patterns given should not begin with `refs/heads`, `refs/tags`, or
+`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
+restrictively, and they must begin with `refs/` when applied to `--glob`
+or `--all`. If a trailing '/{asterisk}' is intended, it must be given
+explicitly.
+
--ignore-missing::
Upon seeing an invalid object name in the input, pretend as if
--
1.8.4.33.gd68f7e8
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
On Mon, Sep 2, 2013 at 3:11 PM, Johannes Sixt j...@kdbg.org wrote:
Am 31.08.2013 01:55, schrieb Junio C Hamano:
People often find git log --branches etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some. The same applies to --tags, --all and --glob.
Teach the revision machinery to remember patterns, and then upon the
next such a globbing option, exclude those that match the pattern.
With this, I can view only my integration branches (e.g. maint,
master, etc.) without topic branches, which are named after two
letters from primary authors' names, slash and topic name.
git rev-list --no-walk --exclude=??/* --branches |
git name-rev --refs refs/heads/* --stdin
This one shows things reachable from local and remote branches that
have not been merged to the integration branches.
git log --remotes --branches --not --exclude=??/* --branches
It may be a bit rough around the edges, in that the pattern to give
the exclude option depends on what globbing option follows. In
these examples, the pattern ??/* is used, not refs/heads/??/*,
because the globbing option that follows the --exclude=pattern
is --branches. As each use of globbing option resets previously
set --exclude, this may not be such a bad thing, though.
I argued --except should trump everything earlier, but the case
involving --not
--branches --except maint --not master
to mean the same as
--branches --except maint master
just does not make sense.
No, but this could make sense:
--branches ^master --except maint --not master
==
--branches --except maint
An alternative would be that --not would divide the command line
arguments into ranges within which one --except would subtract
subsequent refs from earlier globbing arguments in the same range.
That's not simpler to explain than your current proposal.
Something like that can be easily done in my approach:
--- a/revision.c
+++ b/revision.c
@@ -1984,6 +1984,7 @@ static int handle_revision_pseudo_opt(const char
*submodule,
handle_reflog(revs, *flags);
} else if (!strcmp(arg, --not)) {
*flags ^= UNINTERESTING | BOTTOM;
+ *flags = ~SKIP;
} else if (!strcmp(arg, --except)) {
*flags |= SKIP;
} else if (!strcmp(arg, --no-walk)) {
@@ -2628,7 +2629,8 @@ int prepare_revision_walk(struct rev_info *revs)
for (i = 0; i revs-cmdline.nr; i++) {
struct rev_cmdline_entry *ce;
ce = revs-cmdline.rev[i];
- if ((ce-flags SKIP) !refcmp(ce-name, e-name)) {
+ if ((ce-flags SKIP) !refcmp(ce-name, e-name)
+ ((ce-flags UNINTERESTING)
== (e-item-flags UNINTERESTING))) {
e-item-flags =
recalculate_flag(revs, e-item-sha1, ce-name);
goto next;
}
diff --git a/t/t6112-rev-list-except.sh b/t/t6112-rev-list-except.sh
index a40a641..441e1da 100755
--- a/t/t6112-rev-list-except.sh
+++ b/t/t6112-rev-list-except.sh
@@ -57,4 +57,21 @@ test_expect_success 'rev-list --except and --not
with proper flags' '
test_cmp expect actual
'
+test_expect_success 'rev-list --not ranges' '
+
+ git rev-list --topo-order test --not master --except master
test actual
+ git rev-list --topo-order test expect
+ test_cmp expect actual
+'
+
+test_expect_success 'rev-list multiple --not ranges' '
+
+ git checkout -b extra test
+ echo five content
+ git commit -a -m five
+ git rev-list --topo-order test --not master --except master
test --not extra actual
+ git rev-list --topo-order test extra expect
+ test_cmp expect actual
+'
+
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
On 09/02/2013 10:11 PM, Johannes Sixt wrote:
Am 31.08.2013 01:55, schrieb Junio C Hamano:
People often find git log --branches etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some. The same applies to --tags, --all and --glob.
Teach the revision machinery to remember patterns, and then upon the
next such a globbing option, exclude those that match the pattern.
With this, I can view only my integration branches (e.g. maint,
master, etc.) without topic branches, which are named after two
letters from primary authors' names, slash and topic name.
git rev-list --no-walk --exclude=??/* --branches |
git name-rev --refs refs/heads/* --stdin
This one shows things reachable from local and remote branches that
have not been merged to the integration branches.
git log --remotes --branches --not --exclude=??/* --branches
It may be a bit rough around the edges, in that the pattern to give
the exclude option depends on what globbing option follows. In
these examples, the pattern ??/* is used, not refs/heads/??/*,
because the globbing option that follows the --exclude=pattern
is --branches. As each use of globbing option resets previously
set --exclude, this may not be such a bad thing, though.
I argued --except should trump everything earlier, but the case
involving --not
--branches --except maint --not master
to mean the same as
--branches --except maint master
just does not make sense.
An alternative would be that --not would divide the command line
arguments into ranges within which one --except would subtract
subsequent refs from earlier globbing arguments in the same range.
That's not simpler to explain than your current proposal.
So I like the relative simplicity of this approach. Here is a bit of
documentation.
--- 8 ---
Subject: [PATCH] document --exclude option
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Documentation/rev-list-options.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index 5bdfb42..650c252 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -174,6 +174,21 @@ parents) and `--max-parents=-1` (negative numbers denote
no upper limit).
is automatically prepended if missing. If pattern lacks '?',
'{asterisk}',
or '[', '/{asterisk}' at the end is implied.
+--exclude=glob-pattern::
+
+ Do not include refs matching 'glob-pattern' that the next `--all`,
+ `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
+ consider. Repetitions of this option accumulate exclusion patterns
+ up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
+ `--glob` option (other options or arguments do not clear
+ accumlated patterns).
++
+The patterns given should not begin with `refs/heads`, `refs/tags`, or
+`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
+restrictively, and they must begin with `refs/` when applied to `--glob`
s/restrictively/respectively/
+or `--all`. If a trailing '/{asterisk}' is intended, it must be given
+explicitly.
+
--ignore-missing::
Upon seeing an invalid object name in the input, pretend as if
It seems to me that this is growing into a language for expressing
boolean expressions without allowing terms to be combined in the full
generality that, say, a real programming language would allow. Maybe
instead of trying to decide on the perfect grouping and precedence
rules, it would be clearer to allow the user to specify them. I almost
hate to suggest it, but have you considered making the expression
syntax a little bit more flexible by allowing parentheses, à la
find(1), or something analogous?:
'(' --tags --except='v[0-9]*' ')' -o '(' --branches --except='mh/*' ')'
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
On Fri, Aug 30, 2013 at 6:55 PM, Junio C Hamano gits...@pobox.com wrote: People often find git log --branches etc. that includes _all_ branches is cumbersome to use when they want to grab most but except some. The same applies to --tags, --all and --glob. This idea looks very familiar, from the wording of this commit message it seems you came with the idea out of nowhere. Did you? Teach the revision machinery to remember patterns, and then upon the next such a globbing option, exclude those that match the pattern. With this, I can view only my integration branches (e.g. maint, master, etc.) without topic branches, which are named after two letters from primary authors' names, slash and topic name. git rev-list --no-walk --exclude=??/* --branches | git name-rev --refs refs/heads/* --stdin My patch does the trick with: --branches --except --glob='heads/??/*' -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] revision: introduce --exclude=glob to tame wildcards
People often find git log --branches etc. that includes _all_
branches is cumbersome to use when they want to grab most but except
some. The same applies to --tags, --all and --glob.
Teach the revision machinery to remember patterns, and then upon the
next such a globbing option, exclude those that match the pattern.
With this, I can view only my integration branches (e.g. maint,
master, etc.) without topic branches, which are named after two
letters from primary authors' names, slash and topic name.
git rev-list --no-walk --exclude=??/* --branches |
git name-rev --refs refs/heads/* --stdin
This one shows things reachable from local and remote branches that
have not been merged to the integration branches.
git log --remotes --branches --not --exclude=??/* --branches
It may be a bit rough around the edges, in that the pattern to give
the exclude option depends on what globbing option follows. In
these examples, the pattern ??/* is used, not refs/heads/??/*,
because the globbing option that follows the --exclude=pattern
is --branches. As each use of globbing option resets previously
set --exclude, this may not be such a bad thing, though.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Junio C Hamano gits...@pobox.com writes:
It may be a good idea to step back a bit and think of this topic as
a way to enhance the --branches option and its friends with only the
inclusive wildcard semantics. It lets us include those that match
the pattern with --branches=wip/*, but there is no way to say oh
by the way, I do not want those that match this pattern included
when you expand this short-hand. We have --branches=pattern that
is inclusive; perhaps it can be prefixed with --branches=!pattern to
pre-declare whatever the next --branches expands to, do not include
those that match this pattern, or something, which would make the
earlier wip example to be:
--all --not --branches='!wip/*' --branches
So here is a quick attempt at that approach, which does not look
too intrusive.
revision.c | 50 --
revision.h | 3 +++
2 files changed, 51 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index 84ccc05..3e82874 100644
--- a/revision.c
+++ b/revision.c
@@ -1180,11 +1180,28 @@ struct all_refs_cb {
const char *name_for_errormsg;
};
+static int ref_excluded(struct rev_info *revs, const char *path)
+{
+ struct string_list_item *item;
+
+ if (!revs-ref_excludes)
+ return 0;
+ for_each_string_list_item(item, revs-ref_excludes) {
+ if (!fnmatch(item-string, path, 0))
+ return 1;
+ }
+ return 0;
+}
+
static int handle_one_ref(const char *path, const unsigned char *sha1, int
flag, void *cb_data)
{
struct all_refs_cb *cb = cb_data;
- struct object *object = get_reference(cb-all_revs, path, sha1,
- cb-all_flags);
+ struct object *object;
+
+ if (ref_excluded(cb-all_revs, path))
+ return 0;
+
+ object = get_reference(cb-all_revs, path, sha1, cb-all_flags);
add_rev_cmdline(cb-all_revs, object, path, REV_CMD_REF, cb-all_flags);
add_pending_sha1(cb-all_revs, path, sha1, cb-all_flags);
return 0;
@@ -1197,6 +1214,24 @@ static void init_all_refs_cb(struct all_refs_cb *cb,
struct rev_info *revs,
cb-all_flags = flags;
}
+static void clear_ref_exclusion(struct rev_info *revs)
+{
+ if (revs-ref_excludes) {
+ string_list_clear(revs-ref_excludes, 0);
+ free(revs-ref_excludes);
+ }
+ revs-ref_excludes = NULL;
+}
+
+static void add_ref_exclusion(struct rev_info *revs, const char *exclude)
+{
+ if (!revs-ref_excludes) {
+ revs-ref_excludes = xcalloc(1, sizeof(*revs-ref_excludes));
+ revs-ref_excludes-strdup_strings = 1;
+ }
+ string_list_append(revs-ref_excludes, exclude);
+}
+
static void handle_refs(const char *submodule, struct rev_info *revs, unsigned
flags,
int (*for_each)(const char *, each_ref_fn, void *))
{
@@ -1953,33 +1988,44 @@ static int handle_revision_pseudo_opt(const char
*submodule,
if (!strcmp(arg, --all)) {
handle_refs(submodule, revs, *flags, for_each_ref_submodule);
handle_refs(submodule, revs, *flags, head_ref_submodule);
+ clear_ref_exclusion(revs);
} else if (!strcmp(arg, --branches)) {
handle_refs(submodule, revs, *flags,
for_each_branch_ref_submodule);
+ clear_ref_exclusion(revs);
} else if (!strcmp(arg, --bisect)) {
handle_refs(submodule, revs, *flags, for_each_bad_bisect_ref);
handle_refs(submodule, revs, *flags ^ (UNINTERESTING | BOTTOM),
for_each_good_bisect_ref);
revs-bisect = 1;
} else if (!strcmp(arg, --tags)) {
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
On Sat, Aug 31, 2013 at 6:55 AM, Junio C Hamano gits...@pobox.com wrote:
+static int ref_excluded(struct rev_info *revs, const char *path)
+{
+ struct string_list_item *item;
+
+ if (!revs-ref_excludes)
+ return 0;
+ for_each_string_list_item(item, revs-ref_excludes) {
+ if (!fnmatch(item-string, path, 0))
+ return 1;
+ }
+ return 0;
+}
If you pursue this, please use wildmatch instead so it supports foo/**.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] revision: introduce --exclude=glob to tame wildcards
Duy Nguyen pclo...@gmail.com writes:
On Sat, Aug 31, 2013 at 6:55 AM, Junio C Hamano gits...@pobox.com wrote:
+static int ref_excluded(struct rev_info *revs, const char *path)
+{
+ struct string_list_item *item;
+
+ if (!revs-ref_excludes)
+ return 0;
+ for_each_string_list_item(item, revs-ref_excludes) {
+ if (!fnmatch(item-string, path, 0))
+ return 1;
+ }
+ return 0;
+}
If you pursue this, please use wildmatch instead so it supports foo/**.
The thought crossed my mind and I think we should match what the
existing --glob=pattern option does. A cursory look in
refs.c::filter_refs() used by refs.c::for_each_glob_ref_in() tells
me that we are using fnmatch without FNM_PATHNAME, so that is what
the above part does.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
