[RFC] The design of new pathspec features

For those who haven't followed closely, some coming changes allow us to extend current pathspec syntax. We should soon be able to do case-insenstive matching for example, or introduce "**" wildcard that is currently used by gitignore. I just want to discuss about the new syntax and behavior.

Many of these are already implemented in [1]. But I don't want you to bother with buggy code yet. I'll resend it soon after 1.8.2.

--literal-pathspecs ===================

This feature is added by Jeff to disable globbing for all pathspecs. I want to push it a bit further: disable all pathspec magic. This means even ":/" is treated literally when --literal-pathspecs is set. Because the intent behind this, as I understand, is for scripting, it makes sense to keep it as literal as possible.

:(literal) magic ================

This magic is for people who want simple no-globbing pathspec (*). It can be used in combination with other magic such as case-insensitive matching. Incompatible with :(glob) magic below.

Global option --noglob-pathspecs is added to add :(literal) to all. This is very similar to --literal-pathspecs. It just does not disable pathspec magic. :(glob) magic overrides this global option.

(*) you can always disable wildcards by quoting them using backslash, but that's inconvenient

:(glob) magic =============

This magic is for people who want globbing. However, it does _not_ use the same matching mechanism the non-magic pathspec does today. It uses wildmatch(WM_PATHNAME), which basically means '*' does not match slashes and "**" does.

Global option --glob-pathspecs is added to add :(glob) to all pathspec. :(literal) magic overrides this global option.

fnmatch without FNM_PATHNAME is deprecated ==========================================

With the two magic above, people can switch between literal and new globbing. There is no way to regain current matching behavior once --[no]glob-pathspecs is used. And I think that's a good thing. New globbing is more powerful than the current one. At some point, I'd like to switch the matching behavior when neither literal nor magic pathspec is specified. Either:

 - make it literal by default
 - make it new globbing by default

Which is more often used should be come the default. The question is which.

Pathspec mnemonic =================

Are :(literal) and :(glob) used often enough to deserve a short mnemonic (like :/ is equivalent to :(top))? Which symbols should be used? We can only use non-alphanumeric here, and '(', ')', ':' and '/' are taken. It should be friendly to UNIX shell, no quoting is preferred.

Another magic will come soon: case-insensitive matching. We may want to reserve a mnemonic symbol for it as well.

We may also want to reserve option shortcuts for --noglob-pathspecs and --glob-pathspecs. I suspect they'll be used more often.

New way to specify long pathspec magic ======================================

While testing the pathspec magic code, I grow tired of quoting :(glob) every time because '(' is the start of a new shell. Which is one of the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to specify long pathspec magic without quoting.

How about making ":q/xxx/" an equivalence of ":(xxx)"? Any character (except ',') following 'q' is used as separator (similar to s/// from sed). This violates the guidelines set in glossary-content.txt (only use non-alphanumeric).

Another step futher is remove support for ":(xxx)" in favor of ":q(xxx)". We can do it today because I don't think anybody is using ":(top)" (the only supported magic) yet.

[1] https://github.com/pclouds/git/tree/parse-pathspec