On Wed, Dec 19, 2012 at 02:00:03PM -0800, Junio C Hamano wrote: > > Subject: add GIT_PATHSPEC_GLOB environment variable > > Seems cleanly done from a quick look. > > Given that the normal mode of operation is to use globbing, I > suspect that the names would have been more natural if the toggle > were GIT_PATHSPEC_LITERAL and the boolean function were > limit_pathspec_to_literal(), instead of "allow_pathspec_glob()", > sounding as if using glob is done only upon request. > > But that is a minor issue. Yeah, I was trying to avoid the double-negation of "noglob=false" for the default behavior. I guess calling it literal is another way of accomplishing that, and it keeps the default at "false". I don't have a strong preference. > > This patch introduces an environment variable to turn all > > pathspecs into literal strings. This makes it easy to turn > > off the globbing behavior for a whole environment (e.g., if > > you are serving repos via a web interface that is only going > > to use literal programmatic pathspecs), or for a particular > > run. > > I am not sure if "web interface" is a particularly good example, > though. Is it unusual to imagine a Web UI that takes pathspecs from > the user to limit its output (e.g. "diff" or "ls-tree") to those > paths that match them? In such a case, the user would expect their > pathspecs to work the same way as the Git installed on their > desktop, I would think. Yes. If you want to provide for user-provided globbing pathspecs, then you'd have to annotate each invocation with whether you want globbing or not. What I was trying to illustrate was more how "gitweb" will let you click on the "history" link for "foo" in a tree listing, resulting in a page that is generated by calling "git rev-list foo". You would probably not want pathspec globbing there. > Will queue; thanks. Do we want to change the variable name and invert the logic? Now is probably the best time to do 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