On Wed, Dec 19, 2012 at 12:54:04PM -0800, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > ... 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html