Le 28 sept. 2025 à 18:40, Junio C Hamano [off-list ref] a écrit :

"D. Ben Knoble" [off-list ref] 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.

quoted

- 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!