From: <rsbecker@nexbridge.com>
To: "'Junio C Hamano'" <gitster@pobox.com>, <git@vger.kernel.org>
Cc: "'Robert Dailey'" <rcdailey.lists@gmail.com>
Subject: RE: [PATCH] pathspec: correct an empty string used as a pathspec element
Date: Sun, 29 May 2022 19:01:11 -0400 [thread overview]
Message-ID: <032f01d873b0$008c1b50$01a451f0$@nexbridge.com> (raw)
In-Reply-To: <xmqqpmjwx8so.fsf_-_@gitster.g>
On May 29, 2022 6:40 PM, Junio C Hamano wrote:
>Pathspecs with only negative elements did not work with some commands that
>pass the pathspec along to a subprocess. For instance,
>
> $ git add -p -- ':!*.txt'
>
>should add everything except for paths ending in ".txt", but it gets
complaint from
>underlying "diff-index" and aborts.
>
>We used to error out when a pathspec with only negative elements in it,
like the
>one in the above example. Later, 859b7f1d (pathspec:
>don't error out on all-exclusionary pathspec patterns, 2017-02-07) updated
the
>logic to add an empty string as an extra element. The intention was to let
the
>extra element to match everything and let the negative ones given by the
user to
>subtract from it.
>
>At around the same time, we were migrating from "an empty string is a valid
>pathspec element that matches everything" to "either a dot or ":/" is used
to
>match all, and an empty string is rejected", between d426430e (pathspec:
warn on
>empty strings as pathspec,
>2016-06-22) and 9e4e8a64 (pathspec: die on empty strings as pathspec,
2017-06-
>06). I think 9e4e8a64, which happened long after 859b7f1d happened, was
not
>careful enough to turn the empty string 859b7f1d added to either a dot or
":/".
>
>A care should be taken as the definition of "everything" depends on
>subcommand. For the purpose of "add -p", adding a "." to add everything in
the
>current directory is the right thing to do. But for some other commands,
":/" (i.e.
>really really everything, even things outside the current subdirectory) is
the right
>choice.
>
>We would break commands in a big way if we get this wrong, so add a handful
of
>test pieces to make sure the resulting code still excludes the paths that
are
>expected and includes "everything" else.
Thanks for the heads up. I have to check into this for some scripting. Not
worried but glad to know.
Thanks,
--Randall
next prev parent reply other threads:[~2022-05-29 23:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-29 17:27 Excluding paths with wildcard not working with add -p Robert Dailey
2022-05-29 18:25 ` Junio C Hamano
2022-05-29 18:42 ` Junio C Hamano
2022-05-29 22:39 ` [PATCH] pathspec: correct an empty string used as a pathspec element Junio C Hamano
2022-05-29 23:01 ` rsbecker [this message]
2022-05-29 21:15 ` Excluding paths with wildcard not working with add -p Robert Dailey
2022-05-30 17:20 ` 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='032f01d873b0$008c1b50$01a451f0$@nexbridge.com' \
--to=rsbecker@nexbridge.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=rcdailey.lists@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).