Re: [PATCH] add core.pathspecGlob config option

On Wed, Dec 19, 2012 at 12:54:04PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

... doing ":(noglob)" right would mean converting
the whole codebase to use "struct pathspec", as the usual
"const char **pathspec" cannot represent extra per-item
flags.

As that is the longer-term direction we would want to go, I'd rather
not to take the approach in this patch for introducing user-facing
support of literal pathspecs.

Having said that, even when we have the ':(noglob)' magic pathspec
support, it would make sense to introduce a command line option to
make it easier for scripted Porcelains that call plumbing commands
to pass literal pathspecs (i.e. they know exactly what paths they
want to operate, not what patterns the paths they want to operate
would match).

Right, that is my use case. Even once ":(noglob)" exists, it will still
be much simpler for me to use a single option, since I would never have
mixed patterns and literal paths (and I suspect most use cases that
would care about the distinction would be in the same boat). And that is
what led me to submit this at all, as it is not just "well, it is a hack
until :(noglob) works", but "this is not as fine a granularity as
:(noglob), but it better matches what callers want".

I do not think configuration variable makes much sense (unless you are
thinking "git -c core.literalpathspec=true" as that command line
option).

The configuration variable is much more convenient for me, because
otherwise I have to instrument every call to git with a "--no-glob"
option. Because I have a very restricted environment, and happen to know
that globs will _never_ be useful on my repos (or, say, on commands run
by a particular user who has this in their ~/.gitconfig), it makes sense
to just turn off the feature with one switch.

And my thinking was that for people who are not in such a restricted
environment, "git -c core.pathspecglob=false" could serve as that
command-line option, as you mentioned.

It's perhaps a better match to make it an environment variable. Then it
is tied to a particular flow of execution, rather than having it be a
property of a system, user, or repo (which is what config does). So for
my restricted environment, it would be sufficient for me to set the
environment variable for the user who runs the scripts. And people who
want a command-line option can set it via the shell, or we can provide
"git --no-pathspec-glob" to set it.

-Peff