Re: git-diff: --ignore-matching-lines has no effect on the output when --name-only is used

[Junio C Hamano <gitster@pobox.com>]

Lidong Yan <yldhome2d2@gmail.com> writes:

> The `—ignore-matching-lines` options is introduced in 296d4a94e72
> (Michał Kępień 2020-10-20 08:48:09 +0200 5803) Since the Git documentation

WTH is that reference format?

> doesn't specify how git diff --ignore-matching-lines=<regex>
> is supposed to behave when used with --name-only,

True.

Traditionally, these options that deliberately allowed loss of
information (e.g., --name-only that strips _how_ they are different,
--quiet that only talks about if there is anything different) are
meant primarily to be optimization---when it can compute its result
without looking into the blob contents, it is very much encouraged
to do so.  So originally the design principle was that options like
-w -b that needs to look into the blob contents are to be ignored
when computing --name-only and --quiet.

Things gradually have changed, and these days we generally consider
it a bug for the class of options that deliberately lose information
to disable the class of options that require to look into blob
contents to compute the outcome if the output were not losing
information.

"--ignore-matching-lines", together with any options that affect
XDF_IGNORE_WHITESPACE* (like -w, --ignore-space-at-eol) are special
cased to tell the machinery to look at the contents when deciding
what exit code to return:

	if ((options->xdl_opts & XDF_WHITESPACE_FLAGS) ||
	    options->ignore_regex_nr)
		options->flags.diff_from_contents = 1;
	else
		options->flags.diff_from_contents = 0;

so "git diff --ignore-matching-lines --quiet" would already be
operating correctly, I would think.

It is just --raw, --name-only, --name-status, and --checkdiff output
formats that deliberately ignore content based ignore mechanisms.

And I do not think it would be a good change to have them follow
"ignore" bits.  When asked "has this path been modified?"  "what are
the before and after blob object names?" etc., it does not make sense
for the answer to be different depending on the presense of -w or
--ignore-matching options.