From: Brandon Williams <bmwill@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [PATCH v2] ls-files: add pathspec matching for submodules
Date: Tue, 20 Sep 2016 09:30:27 -0700 [thread overview]
Message-ID: <CAKoko1oU+QR61Vy0eSxaRe_w8u4q_bC9gx9H7oMqH=CwNzBVCA@mail.gmail.com> (raw)
In-Reply-To: <xmqqh99bcw6m.fsf@gitster.mtv.corp.google.com>
On Mon, Sep 19, 2016 at 4:21 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> As the previous one that used a wrong (sorry) argument is not even
> in 'next' yet, let's pretend that it never happened. It is OK to
> still keep it and this patch as two separate steps, i.e. a topic
> with two patches in it.
>
> That means that this patch will become 2/2 of a series, and 1/2 is
> rerolled to use submodule_prefix from the get-go, without ever
> introducing output_path_prefix variable, so that many of the above
> lines we won't have to review in 2/2.
Ah ok. Would you like me to resend the first patch with the desired
change then?
>
>> + /*
>> + * Pass in the original pathspec args. The submodule will be
>> + * responsible for prepending the 'submodule_prefix' prior to comparing
>> + * against the pathspec for matches.
>> + */
>
> Good.
>
>> + argv_array_push(&cp.args, "--");
>> + for (i = 0; i < pathspec.nr; ++i)
>> + argv_array_push(&cp.args, pathspec.items[i].original);
>> +
>
> Please prefer post-increment i++ over pre-increment ++i when writing
> a for(;;) loop, unless there is a strong reason not to (familiarlity
> in C++ is not a good reason).
I had a compiler instructor drill into my head that ++i in a for loop
was faster historically
since it wouldn't have to create a temporary value. Of course now a days there
probably isn't much (or any) difference between the two. If post-fix
operators are the
norm in git code then I can try to remember to use them :)
>> +
>> + if (item->flags & PATHSPEC_ONESTAR) {
>> + return WM_MATCH;
>> + } else if (item->magic & PATHSPEC_GLOB) {
>> + return wildmatch(pattern, string,
>> + WM_PATHNAME |
>> + (item->magic & PATHSPEC_ICASE ?
>> + WM_CASEFOLD : 0),
>> + NULL);
>
> Isn't this last one overly tight? I am wondering about a scenario
> where you have a submodule at "sub/" in the superproject, and "sub/"
> has a "file" at the top of its working tree. And you do:
>
> git ls-files --recurse-submodules ':(glob)??b/fi?e'
>
> at the top of the superproject. The "pattern" would be '??b/fi?e"
> while string would be 'sub', and wildmatch() would not like it, but
> there is no way for this caller to append anything to 'sub' before
> making this call, as it hasn't looked into what paths appear in the
> submodule repository (and it should not want to). And I think we
> would want it to recurse to find sub/file. IOW, this looks like a
> false negative we must avoid in this function. As we cannot afford
> to check if anything that matches 'fi?e' is in the index file of the
> submodule repository, we shouldn't try to match 'fi?e' portion of
> the given pathspec pattern.
good point. Let me think about this some more.
next prev parent reply other threads:[~2016-09-20 16:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-14 23:57 [RFC] extending pathspec support to submodules Brandon Williams
2016-09-15 11:57 ` Heiko Voigt
2016-09-15 15:26 ` Brandon Williams
2016-09-15 22:08 ` Junio C Hamano
2016-09-15 22:28 ` Stefan Beller
2016-09-16 9:34 ` Heiko Voigt
2016-09-16 18:40 ` Brandon Williams
2016-09-17 0:59 ` [PATCH] ls-files: add pathspec matching for submodules Brandon Williams
2016-09-17 3:46 ` Junio C Hamano
2016-09-18 18:40 ` Brandon Williams
2016-09-19 17:00 ` Junio C Hamano
2016-09-19 17:26 ` Brandon Williams
2016-09-19 18:04 ` Junio C Hamano
2016-09-19 18:20 ` Brandon Williams
2016-09-19 18:22 ` Junio C Hamano
2016-09-19 18:30 ` Brandon Williams
2016-09-19 18:34 ` Junio C Hamano
2016-09-19 18:35 ` Brandon Williams
2016-09-19 18:52 ` [PATCH v2] " Brandon Williams
2016-09-19 23:21 ` Junio C Hamano
2016-09-20 16:30 ` Brandon Williams [this message]
2016-09-20 21:03 ` Brandon Williams
2016-09-21 17:12 ` Junio C Hamano
2016-09-21 17:49 ` Junio C Hamano
2016-09-19 18:18 ` [PATCH] " 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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAKoko1oU+QR61Vy0eSxaRe_w8u4q_bC9gx9H7oMqH=CwNzBVCA@mail.gmail.com' \
--to=bmwill@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).