Re: [PATCH] add GIT_PATHSPEC_GLOB environment variable

On Wed, Dec 19, 2012 at 02:00:03PM -0800, Junio C Hamano wrote:

quoted

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.

quoted

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