From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Sruteesh Kumar <sruteesh.oss@protonmail.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH] match_pathname(): give fnmatch one char of prefix context
Date: Mon, 27 Oct 2025 08:35:23 -0700 [thread overview]
Message-ID: <xmqq4irkl5ms.fsf@gitster.g> (raw)
In-Reply-To: <20251027142902.GB2758515@coredump.intra.peff.net> (Jeff King's message of "Mon, 27 Oct 2025 10:29:02 -0400")
Jeff King <peff@peff.net> writes:
>> I added the "limit to known bad case" in the illustration not for
>> performance but for correctness. This was because just like we
>> weren't convinced that the "**/" may be the only case that breaks
>> the existing optimization, I was worried if stepping back by one
>> byte may somehow make a pattern that should not match mistakenly
>> match.
>
> Hmm, I hadn't really considered that. This is mostly hand-waving, but it
> feels unlikely to cause issues because we're giving fnmatch() more
> context, and never less.
Yup. The above was an explanation of what I was thinking when I
wrote it, not a justification. I haven't thought of a single case
that it would hurt to step back by one byte.
> BTW, there was another bug mentioned in that original issue around
> backslash handling. I didn't investigate it at all, though. It didn't
> look like it would be related to this optimization, so I think we can
> just consider this fix independently.
Hmph, backslash is GIT_GLOB_SPECIAL so nowildcard prefix would stop
before it. Could it be that we mistake it as a directory separator?
I _think_ we are still cleanly distinguish paths from the filesystem
(which could use backslash as directory separator on some platforms)
and the pathspec (which defines the slash as the sole directory
separator), and have platform-specific fspathncmp() to absorb the
differences when matching one with the other. And nowildcard_len is
all about the pathspec, so it probably is something else.
\Thanks.
next prev parent reply other threads:[~2025-10-27 15:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-10 14:57 Probable issue with code/documentation Sruteesh Kumar
2025-10-14 0:34 ` [PATCH] match_pathname(): give fnmatch one char of prefix context Jeff King
2025-10-14 3:09 ` Jeff King
2025-10-22 16:19 ` Sruteesh Kumar
2025-10-23 20:28 ` Junio C Hamano
2025-10-24 18:28 ` Sruteesh Kumar
2025-10-26 15:18 ` Jeff King
2025-10-26 15:26 ` Jeff King
2025-10-26 15:40 ` [PATCH v2 0/2] fix "foo**/bar" matching "foobar" Jeff King
2025-10-26 15:41 ` [PATCH v2 1/2] match_pathname(): reorder prefix-match check Jeff King
2025-10-26 15:42 ` [PATCH v2 2/2] match_pathname(): give fnmatch one char of prefix context Jeff King
2025-10-26 23:29 ` [PATCH] " Junio C Hamano
2025-10-27 14:29 ` Jeff King
2025-10-27 15:35 ` Junio C Hamano [this message]
2025-10-28 23:19 ` Jeff King
2025-10-29 15:32 ` [PATCH] doc: document backslash in gitignore patterns Jeff King
2025-10-29 15:55 ` Jeff King
2025-10-30 13:40 ` D. Ben Knoble
2025-10-30 15:08 ` Jeff King
2025-10-30 16:05 ` Ben Knoble
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=xmqq4irkl5ms.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sruteesh.oss@protonmail.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 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 NNTP newsgroup(s).