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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 27, 2025, 00:16 UTC
Message-ID: <xmqqv7nezdw2.fsf@gitster.g>
In-Reply-To: <CALnO6CAOOTBQf3s9B1G8AgwcbYnv5VNY63q-6bGPeoaLy208rg@mail.gmail.com>

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

> 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 ":^:".

> - "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.

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.