Re: [RFC] The design of new pathspec features

Duy Nguyen [off-list ref] writes:

:(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

Have you considered if it may be helpful to have a :(literal) magic
(or any magic in general) that applies only to the first N
characters of the pathspec pattern?

When you are in subdirectory and do a pathspec limited operation,
e.g.

        cd Documentation && git ls-files "*.txt"

we internaly do an equivalent of this:

    (1) first find out the "prefix", e.g. "Documentation/" in this
        case;
    (2) prepend the prefix to user-supplied pathspecs, e.g. yielding
        "Documentation/*.txt" in this case; and
    (3) use the resulting pathspecs to match against full pathnames
        relative to the root of the working tree.

If the prefix had globbing character in it (e.g. we started in a
directory "D*cumentati*n" instead), we still should make sure that
that part matches literally, while allowing the globbing in
user-supplied part of the pathspec (e.g. "*.txt").  In the built in
code, you can work with the struct pathspec directly and mark the
entire prefix part with nowildcard_len field to match literally, but
if the above three-step logic needs to be implemented by a Porcelain
script like old days, they would need to quote glob specials in the
prefix part before appending user-supplied part to form the full
pathspec string.

I personally think we do not need to support something like this:

	prefix=$(git rev-parse --show-prefix)
	n=${#prefix}
        pathspec=":(literal-$n)$prefix$1"

but other aspiring Porcelain script writers may disagree and would
want to have it.  We can always solve it by giving them an easy and
uniform way to get the glob-quoted version of prefix to solve this
particular issue, i.e.

	prefixq=$(git rev-parse --show-prefix-glob-quoted)
        pathspec="$prefixq$1"

but magic that applies only to a substring may have other uses.

If you do not immediately think of any, let's not overengineer this.

Thanks.

On Tue, Jan 29, 2013 at 12:33 PM, Junio C Hamano [off-list ref] wrote:

Have you considered if it may be helpful to have a :(literal) magic
(or any magic in general) that applies only to the first N
characters of the pathspec pattern?

Not user-driven. But the prefix part is :(literal)-applied. :(glob) is
currently implemented this way, using nowildcard_len as you mentioned.
:(icase) is more complicated and does not follow yet.

I personally think we do not need to support something like this:

        prefix=$(git rev-parse --show-prefix)
        n=${#prefix}
        pathspec=":(literal-$n)$prefix$1"

but other aspiring Porcelain script writers may disagree and would
want to have it.  We can always solve it by giving them an easy and
uniform way to get the glob-quoted version of prefix to solve this
particular issue, i.e.

        prefixq=$(git rev-parse --show-prefix-glob-quoted)
        pathspec="$prefixq$1"

but magic that applies only to a substring may have other uses.

Yeah, that simplifies things. Supporting applying magic over just
parts of the pathspec pattern sounds complex. Just a small
modification. That rev-parse needs to look at "$1" as well. If
:(literal) is already specified, glob quoting will backfire. The user
script can deal with that, but it's harder (e.g. parsing magic from
scripts and deal with magic combination) than letting rev-parse does
it.

I've done some form of this already, for supporting add--interactive.
git-add prefixes the pathspec but keeps all the magic in place, before
passing pathspec to add--interactive. But I missed the quoting point
you mentioned above. I probably need de-quoting the prefix as well.
Many optimizations stop short at the sign of any glob symbols,
including backslash. This could be a new task for wildmatch.
-- 
Duy