From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Per Cederqvist <cederp@opera.com>,
Jens Lehmann <Jens.Lehmann@web.de>,
"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] submodule helper: accept '.' for repositories with no submodules
Date: Tue, 22 Mar 2016 14:38:59 -0700 [thread overview]
Message-ID: <xmqqtwjyfb0s.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79ka=EJ-L+Zaqh0kWUdjmyUva3fEcbwJn18uxshe3R5ABBQ@mail.gmail.com> (Stefan Beller's message of "Tue, 22 Mar 2016 14:16:40 -0700")
Stefan Beller <sbeller@google.com> writes:
>> I do not think that buys us much. You have already shown how to
>> implement "filter first and then pathspec match" if a caller
>> wants to (which turned out to be a regression in this case, but
>> that is besides the point).
>
> And by including this filtering into the pathspec machine we can pass
> a flag DONT_BREAK_ON_NO_FILTER_RESULTS_WHEN_HAVING_OTHER_MATCHES
> (name for illustration purpose only ;) which is how I understand this
> regression?
But you do not even need that if you fix the regression with
something like this, no? Do we need to add complexity to pathspec
machinery only to make it easier to misuse it and then add another
DONT_BREAK_... band-aid to fix a bug that can come from such a
misuse?
builtin/submodule--helper.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index ed764c9..740b57a 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -37,10 +37,11 @@ static int module_list_compute(int argc, const char **argv,
for (i = 0; i < active_nr; i++) {
const struct cache_entry *ce = active_cache[i];
- if (!S_ISGITLINK(ce->ce_mode) ||
- !match_pathspec(pathspec, ce->name, ce_namelen(ce),
+ if (!match_pathspec(pathspec, ce->name, ce_namelen(ce),
0, ps_matched, 1))
continue;
+ if (!S_ISGITLINK(ce->ce_mode))
+ continue;
ALLOC_GROW(list->entries, list->nr + 1, list->alloc);
list->entries[list->nr++] = ce;
next prev parent reply other threads:[~2016-03-22 21:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-22 17:59 [PATCH] submodule helper: accept '.' for repositories with no submodules Stefan Beller
2016-03-22 18:53 ` Junio C Hamano
2016-03-22 19:30 ` Stefan Beller
2016-03-22 20:06 ` Junio C Hamano
2016-03-22 21:16 ` Stefan Beller
2016-03-22 21:38 ` Junio C Hamano [this message]
2016-03-22 21:47 ` Stefan Beller
2016-03-22 22:04 ` Junio C Hamano
2016-03-22 22:10 ` Stefan Beller
2016-03-22 22:50 ` Junio C Hamano
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=xmqqtwjyfb0s.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Jens.Lehmann@web.de \
--cc=cederp@opera.com \
--cc=git@vger.kernel.org \
--cc=sbeller@google.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.