On Wed, Jul 30, 2025 at 05:49:29PM -0400, D. Ben Knoble wrote: > 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? Yeah, I'd think so. But it's worse than that, even. According to the glossary definition you showed: In the short form, the leading colon `:` is followed by zero or more "magic signature" letters (which optionally is terminated by another colon `:`) we allow multiple bits of magic. So the code in check_filename() that looks for ":/", ":^", etc would be fooled when seeing more than one character, like: ":/^exclude-from-root". AFAICT there are only two short magic types, so I guess nobody has really run into this before. Also, I guess this function ought to be respecting the literal_pathspecs global? The actual pathspec parser does. If we can, we probably ought to be feeding the paths to a function like pathspec.c:parse_element_magic() and then checking the resulting flags (and skipping past the prefix as it indicates). -Peff PS I didn't even know that we allowed multiple short items or a trailing colon until your email! Hidden corners of Git.
