On Sat, Jul 26, 2025 at 8:16 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> "D. Ben Knoble" <ben.knoble@xxxxxxxxx> 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 ":^:".
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
^).
>
> > - "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
