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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2025, 05:56 UTC
Message-ID: <xmqqbjoxgd83.fsf@gitster.g>
In-Reply-To: <20250802185238.GE1773585@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> But here's the interesting part: it breaks a bunch of tests. They all
> seem to be doing things like ":file.txt". In check_filename() right now
> we treat that literally. But as a pathspec, it is technically "colon
> followed by zero or more magic signature letters", and it is eaten.

Hmph. Shouldn't the definition be "colon and then one or more magic signature letters", then? ":file.txt" to name the blob object at path file.txt in the index is fairly common "rev" and it is a shame that it has to become ambiguous with a pathspec element.

Show 5 quoted lines

> So I wonder if we have painted ourselves into a compatibility corner a
> bit, if we have two conflicting expectations. We might be better off
> just teaching check_filename() to parse multiple of [^/!] and the
> trailing colon. It's horrible and not great for maintainability, but
> this syntax is not something that changes often.

Ah, OK.

So the idea is that when given _as_ a pathspec element (e.g., after an explicit "--" separator), we do want to interpret ":file.txt" as the same as "file.txt", but when dwimming to sift revs and pathspec elements apart, prefer to take it as a blob object name in the index?

I guess that would work better than the current code (or straight "use the full pathspec parser" approach) from the compatibility viewpoint.

Thanks.