All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] ls-files: add pathspec matching for submodules
Date: Wed, 21 Sep 2016 16:23:12 -0700	[thread overview]
Message-ID: <CAKoko1oacXxrSMZBvfM9X6iGDq+KcUUZnUrD2qD3X8+ze8vUXg@mail.gmail.com> (raw)
In-Reply-To: <xmqqtwd86f0q.fsf@gitster.mtv.corp.google.com>

On Wed, Sep 21, 2016 at 3:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Sounds sensible.  Just a minor nit in terminology, but I think we
> fairly consistently say "a superproject contains submodules" (run
> "git grep -E 'super *(module|project)'").
>
> I'd suggest s/super module/superproject/ for consistency.

Will do.

> An example of this test would be to match pathspec "sub/file" with
> submodule path "sub"?

Yep,  I believe there's a test for that case

> item->match[namelen] is accessed without checking if item->match[]
> is long enough here; shouldn't item->len be checked before doing
> that?

Oh right!  Good catch.

>
> Hmph, isn't this the one that is allowed produce false positive but
> cannot afford to give any false negative?  It feels a bit strange
> that the code checks two cases where we can positively say that it
> is worth descending into, and falling through would give "no this
> will never match".  That sounds like invitation for false negatives.
>
> IOW, I would have expected
>
>         if (flags & DO_MATCH_SUBMODULE) {
>                 if (may match in this case)
>                         return MATCHED_RECURSIVE;
>                 if (may match in this other case)
>                         return MATCHED_RECURSIVE;
>                 ...
>                 if (obviously cannot match in this case)
>                         return 0;
>                 if (obviously cannot match in this other case)
>                         return 0;
>                 /* otherwise we cannot say */
>                 return MATCHED_RECURSIVELY;
>         }
>
> as the general code structure.
>
> Fully spelled out,
>
>         if (flags & DO_MATCH_SUBMODULE) {
>                 /* Check if the name is a literal prefix of the pathspec */
>                 if (namelen < item->len &&
>                     item->match[namelen] == '/' &&
>                     !ps_strncmp(item, match, name, namelen))
>                         return MATCHED_RECURSIVE;
>
>                 /* Does the literal leading part have chance of matching? */
>                 if (item->nowildcard_len < item->len &&
>                     namelen <= item->nowildcard_len &&
>                     ps_strncmp(item, match, name, namelen))
>                         return 0; /* no way "su?/file" can match "sib" */
>
>                 /* Otherwise we cannot say */
>                 return MATCHED_RECURSIVELY;
>         }
>
> or something like that.  There may be other "obviously cannot match"
> cases we may want to add further.
>
> Thanks.

You're right it should be structured the other way.

  reply	other threads:[~2016-09-21 23:23 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-21 22:04 [PATCH 1/2] ls-files: adding support for submodules Brandon Williams
2016-09-21 22:04 ` [PATCH 2/2] ls-files: add pathspec matching " Brandon Williams
2016-09-21 22:53   ` Junio C Hamano
2016-09-21 23:23     ` Brandon Williams [this message]
2016-09-21 23:28       ` [PATCH 2/2 v2] " Brandon Williams
2016-09-23 18:48         ` Junio C Hamano
2016-09-23 19:20         ` Junio C Hamano
2016-09-23 20:49           ` Brandon Williams
2016-09-21 22:08 ` [PATCH 1/2] ls-files: adding support " Brandon Williams
2016-09-21 22:28   ` Junio C Hamano
2016-09-21 22:38     ` Brandon Williams
2016-09-21 22:42       ` [PATCH 1/2] ls-files: optionally recurse into submodules Brandon Williams
2016-09-22  6:20         ` Jeff King
2016-09-23 23:31           ` Brandon Williams
2016-09-21 23:13       ` [PATCH 1/2] ls-files: adding support for submodules Junio C Hamano
2016-09-22  4:18         ` Jeff King
2016-09-22 16:04           ` Stefan Beller
2016-09-22 18:13           ` Junio C Hamano
2016-09-23  3:41             ` Jeff King
2016-09-23  5:47               ` Stefan Beller
2016-09-23  6:06                 ` Jeff King
2016-09-23 16:16                   ` Brandon Williams
2016-09-23 16:34                     ` Stefan Beller
2016-09-25 11:03                       ` Nazri Ramliy
2016-09-27 21:38             ` Junio C Hamano
2016-09-27 21:48               ` Brandon Williams
2016-09-27 22:01                 ` Junio C Hamano
2016-09-27 22:09                   ` Brandon Williams
2016-09-27 22:23                     ` 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=CAKoko1oacXxrSMZBvfM9X6iGDq+KcUUZnUrD2qD3X8+ze8vUXg@mail.gmail.com \
    --to=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.