Lidong Yan <yldhome2d2@xxxxxxxxx> 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.
