From: Ben Knoble <ben.knoble@gmail.com>
Date: Mon, 29 Sep 2025 16:42:53 GMT
Subject: Re: [PATCH v2 0/3] Support :(optional) filepaths
Message-ID: <6646024D-319D-47D9-805A-CEB3A620E4BC@gmail.com>
In-Reply-To: <xmqqh5wm5hgu.fsf@gitster.g>


> Le 28 sept. 2025 à 18:40, Junio C Hamano <gitster@pobox.com> a écrit :
> 
> "D. Ben Knoble" <ben.knoble+github@gmail.com> writes:
> 
> Before "notes" you would want an overall description of what the
> topic is for those who no longer remember the previous iteration,
> or for those this iteration is the first one they see.

Agreed, thanks.

>> - I'm least sure of the 3rd patch and am happy to drop it in support of
>>  the first 2. I think it might be better to (a) integrate :(optional)
>>  support as pathspec magic and (b) use pathspec magic in parse-options
>>  when getting filenames. But I'm not sure, and this has other
>>  ramifications I'm not prepared to deal with. (For example: `git grep
>>  path <file>… :(optional)non-existent` could pretend like
>>  `non-existent` was never given?)
> 
> While it might not hurt, I do not see a need for such a support.
> 
> Pathspec _is_ a pattern.  If an existing path does not match the
> pattern, there is no ill effect.  In other words, in this command
> invocation:
> 
>    $ git grep -e needle -- Makefile no-such-file.txt
> 
> neither Makefile or no-such-file.txt is required nor optional.  If
> there are paths that match these two "patterns" among the paths in
> the working tree that are known to the index, the contents of these
> paths are inspected by the command.  If no paths match the patterns,
> that is fine as well.
> 
> The command line parser helpfully offers to notice a pathspec
> pattern that did not match any path when you do not give "--", but
> that is up to the caller of match_pathspec() API to do so.  The
> pathspec machinery only reports if each pathspec element matched a
> path in its seen[] array, and the caller can use that information to
> report which pathspec elements did not contribute to finding the set
> of paths to work on.

I must have been thinking of the case without --, which triggers the usual ambiguity error. Either way, for now, I think a smaller feature is better :)

> Will queue.  Thanks for resurrecting the topic.

Thanks!