git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Thomas Haller <thaller@redhat.com>
Cc: git@vger.kernel.org
Subject: Re: [bug] git-ls-files sometimes does not list files with pathspec magic ":(exclude)"
Date: Wed, 13 Jan 2021 18:07:56 -0800	[thread overview]
Message-ID: <xmqqa6tc1dab.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <e2dbe996f6a7285fe0487e34d65eccf712867547.camel@redhat.com> (Thomas Haller's message of "Wed, 13 Jan 2021 18:41:28 +0100")

Thomas Haller <thaller@redhat.com> writes:

>       git ls-files -- src/platform/ ":(exclude)shared/n-acd"

This does look interesting.

$ git ls-files -- src/platform/ ":(exclude)shared/n-acd"
$ git ls-files -- src/platform/ ":(exclude)??????/?????"
$ git ls-files -- src/platform/ ":(exclude)??????/????"
$ git ls-files -- src/platform/ ":(exclude)??????/???"
$ git ls-files -- src/platform/ ":(exclude)??????/??"
$ git ls-files -- src/platform/ ":(exclude)??????/?"

None of the above gives any output.  And the '/' seems to be a red
herring.  None of the below (where the '/' in the exclude pathspec
is replaced with a single '?') gives any output, either.

$ git ls-files -- src/platform/ ":(exclude)????????????"
$ git ls-files -- src/platform/ ":(exclude)???????????"
$ git ls-files -- src/platform/ ":(exclude)??????????"
$ git ls-files -- src/platform/ ":(exclude)?????????"
$ git ls-files -- src/platform/ ":(exclude)????????"

But if we add one more "?" to the longuest ones, i.e.

$ git ls-files -- src/platform/ ":(exclude)?????????????"
$ git ls-files -- src/platform/ ":(exclude)shared/n-acd?"

we start seeing output.

What is curious is that the longest problematic negative pathspec,
"shared/n-acd" or "????????????", have the same length as
"src/platform" without the trailing slash.

    "shared/n-acd"
    "src/platform/"
    "????????????"

The rule IIUC is that a path must match one of the positive pathspec
and none of the negative pathspec, but it looks as if there is some
bogus optimization based on string length.

An experiment.  These ought to do the same as the first exacmple:

$ git ls-files -- src/platform/ ":(exclude)shared/n-ac[d]"
$ git ls-files -- src/platform/ ":(exclude)shared/n-[acd][acd][acd]"

but probably because of the character class [d], it seems to
defeat/bypass the broken "optimization" and gives what we expect
back.

I'll have to go back to the desk where I have a development
environment (not an end user enviornment) to dig deeper, but this is
intriguing.  I'll look more later unless somebody else beats me to
it.

Thanks for a report.

  reply	other threads:[~2021-01-14  2:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-13 17:41 [bug] git-ls-files sometimes does not list files with pathspec magic ":(exclude)" Thomas Haller
2021-01-14  2:07 ` Junio C Hamano [this message]
2021-01-14 20:21   ` Jeff King

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=xmqqa6tc1dab.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=thaller@redhat.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).