Re: [RFC] The design of new pathspec features

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 29, 2013, 05:33 UTC
Message-ID: <7vd2wotuxm.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130129043517.GA2878@duynguyen-vnpc.dek-tpc.internal>

Duy Nguyen <pclouds@gmail.com> writes:

Show 13 quoted lines

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