Re: [PATCH] pathspec: reserve some letters after a colon pathspec

Michael J Gruber [off-list ref] writes:

Junio C Hamano venit, vidit, dixit 23.03.2011 19:04:
...

quoted

Here is a weather-baloon.  I will use colon below as the magic introducer,
as I don't care very deeply about the choice of it.

 - "^:([^\w\d]+)(.*)$", that is "a magic introducer followed by a sequence
   of non-alnum followed by the remainder" means that the part that is
   given to the matching engine is $2, and each gibberish character in $1
   determines what magic is requested when the matching engine does its
   work.  Among the gibberish that can be in $1, we currently would want
   to support:

    . '/' denotes that $2 is relative to root of the working tree, i.e. do
      not add 'prefix' to it at the left.

    . '!' denotes that the matching with $2 should not honor globbing.

   e.g.

    ":/*lib/**/foo.h", if '*' denoted recursive glob support for '**/' to
    mean "zero-or-more levels of any directory" [*1*], it would find any
    foo.h in a directory 'lib' or its subdirectory that is found in
    anywhere in the working tree.

 - "^:((?:[-a-z]+)(?:,[-a-z+]+)*):(.*)$", that is "a magic introducer,
   followed by one or more alpha-string separated with comma, followed
   by a magic terminator, and the remainder" means that the remainder is
   what is given to the matching engine, and the alpha-strings spell out
   the name of the magic.  We currently would want to support:

    . 'full-tree' means exactly the same as '/' mnemonic above.
    . 'noglob' means exactly the same as '!' mnemonic.

   e.g.

   ":full-tree,recursive-glob:lib/**/foo.h" would be how you fully spell
   the above example in the mnemonic section [*2*].

I like this a lot, especially the fact that we would have descriptive
long names as well as short versions for a subset! Two remarks:

:(symlink|submodule|directory|file): would fit into that scheme (for use
in .gitattributes), though I'm not sure we want that for general
pathspecs.

I do not offhand think it is a good idea.  While traversing history the
pathspec matcher often does not have the mode information extracted from
the tree object in the codepath it inspects the name, so it would be very
costly, I don't think it would particularly be useful, and pathspec is
about names and not about types.

A magic that says "please match case insensitively", so that we do not
have to write "git log -- '[Rr][Ee][Aa][Dd][Mm][Ee]'" would be very
useful.  Perhaps "gibberish" is not a good long term solution after all,
as a natural short-hand for that magic would be a single letter 'i'
somewhere, similar to (?i) in pcre.