Re: [PATCH] add core.pathspecGlob config option

On Wed, Dec 19, 2012 at 10:55:43PM -0500, Jeff King wrote:

On Wed, Dec 19, 2012 at 07:51:16PM -0800, Junio C Hamano wrote:

quoted

quoted

++		if (limit_pathspec_to_literal())
++			item->nowildcard_len = item->len;
++		else {
++			item->nowildcard_len = simple_length(path);
++			if (item->nowildcard_len < item->len) {
++				pathspec->has_wildcard = 1;
++				if (path[item->nowildcard_len] == '*' &&
++				    no_wildcard(path + item->nowildcard_len + 1))
++					item->flags |= PATHSPEC_ONESTAR;
++			}
 +		}

Hmph.  I thought that returning the length without any "stop at glob
special" trick from simple_length() would be a simpler resolution.

That is what is queued at the tip of 'pu', anyway.

I don't think we can make a change in simple_length. It gets used not
only for pathspecs, but also for parsing exclude patterns, which I do
not think should be affected by this option.

Our test suite wouldn't catch such a misfeature, of course, because the
feature is not turned on by default. But I found it instructive to run
all of the tests with GIT_LITERAL_PATHSPECS on. There are failures, of
course, but by inspecting each failure you can see that it is an
intended effect of the patch (i.e., each tries to use a wildcard
pathspec, which no longer works).

When you suggested changing common_prefix, I ran such a test both with
and without the change[1] and confirmed that it did not change the set
of failure sites. I did not try it, but I suspect running such a test
with the tip of pu would reveal new failures in the .gitignore tests.

-Peff

[1] This is in addition to reading and reasoning about the code, of
    course. I would not consider this a very robust form of testing,
    though a test failure which cannot be easily explained would be a
    good starting point for investigation.