Re: Why does git-grep appear to treat exclude pathspecs differently?

On Sat, Jul 26, 2025 at 8:16 PM Junio C Hamano [off-list ref] wrote:

"D. Ben Knoble" [off-list ref] writes:

quoted

With Git 2.48.1, I observe the following behavior:

- "git ls-files :^:Documentation/RelNotes | grep Rel" yields
"RelNotes", as expected

It is deliberately confusing to spell ":(exclude)" as ":^:".

What makes you say that? It's documented in "git help revisions":

           A pathspec that begins with a colon : has special meaning. In the
           short form, the leading colon : is followed by zero or more "magic
           signature" letters (which optionally is terminated by another colon
           :), and the remainder is the pattern to match against the path.

and

           exclude
               After a path matches any non-exclude pathspec, it will be run
               through all exclude pathspecs (magic signature: ! or its synonym
               ^).

quoted

- "git grep squash :^:Documentation/RelNotes" yields the error

fatal: ambiguous argument ':^:Documentation/RelNotes': unknown
revision or path not in the working tree.

I think if you write it in longhand,

    $ git grep squash ':(exclude)Documentation/RelNotes'

you would not see such an error.

Indeed, I left this syntax out of my original, but it works.

The error message comes from setup.c:die_verify_filename(), I think,
and setup.c:looks_like_pathspec() allows the control flow to avoid
calling that filename verification code path.  It knows to let the
longhand magic pathspec go, and it may be trivial to teach it a
shorthand magic too, but I offhand do not know the implications of
such a change---there might be unintended consequences.

Hm. Running a debugger, this looks accurate. We are in the
"!seen_dashdash" case of builtin/grep.c, with the call

    verify_filename(prefix=0x0000000000000000,
arg=":^:Documentation/RelNotes", diagnose_misspelt_rev=1)

which eventually dies as noted. However:

- looks_like_pathspec() only checks for long magic, as you noted
- setup.c:check_filename() looks for short-magic, too, but only
considers ":^" to work like a pathname if we're excluding everything?

I think what I find confusing is that, while this is definitely a DWIM
case for git-grep, it doesn't seem to do DWIM :) We are verifying that
the remaining arguments are filenames, but couldn't they really be
full pathspecs, as long as they aren't revisions?

The difference for "^:<path>" from ":^:<path>", just to complete the
story, is that in setup.c:check_filename() we try to stat whatever
comes after ":^":
- for the former, that's <path> and we are ok
- for the latter, that's :<path>, fail.

So it seems like the places that check for short-magic should also
consider the optional trailing colon?

-- 
D. Ben Knoble