Re: [PATCH] add GIT_PATHSPEC_GLOB environment variable

[Jeff King <peff@peff.net>]

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