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