Nguyễn Thái Ngọc Duy  <> writes:

> :(prefix) is in the long form. Suppose people pass :!foo with '!'
> being the short form of magic 'bar', the code will happily turn it to
> :(prefix..)!foo, which makes '!' part of the path and no longer a magic.
> The correct form must be ':(prefix..,bar)foo', but as so far we
> haven't had any magic in short form yet (*), the code to convert from
> short form to long one will be inactive anyway. Let's postpone it
> until a real short form magic appears.
> (*) The short form magic '/' is a special case and won't be caught by
> this die(), which is correct. When '/' magic is detected, prefixlen is
> set back to 0 and the whole "if (prefixlen..)" block is skipped.
> Signed-off-by: Nguyễn Thái Ngọc Duy <>
> ---
>  fixes on top of nd/magic-pathspec.
>  pathspec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> diff --git a/pathspec.c b/pathspec.c
> index d9f4143..62fde50 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -231,7 +231,9 @@ static unsigned prefix_pathspec(struct pathspec_item 
> *item,
>               const char *start = elt;
>               if (prefixlen && !literal_global) {
>                       /* Preserve the actual prefix length of each pattern */
> -                     if (long_magic_end) {
> +                     if (short_magic)
> +                             die("BUG: prefixing on short magic is not 
> supported");
> +                     else if (long_magic_end) {
>                               strbuf_add(&sb, start, long_magic_end - start);
>                               strbuf_addf(&sb, ",prefix:%d", prefixlen);
>                               start = long_magic_end;


I wonder if we should start thinking about removing the big
"NEEDSWORK" comment in front of this function.

Also the pathspec_magic[] array was the table-driven way that was
meant to be enhanced to fit future needs to parse all supported
types of pathspec magic, but it seems that "prefix:12" magic is
implemented using a custom/special case code.  We may want to see if
we want to enrich the parser to fold this to match the table-driven
approach better someday---this is not urgent as we are not adding
any new pathspec magic now.

Will queue.  Thanks.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to