Lidong Yan <yldhome2d2@xxxxxxxxx> writes:
> Previously, the `-I<regex>` option was inconsistently applied across
> various `git diff` output formats. In some cases, files would appear
> in the `--name-only` output but not in the accompanying `--stat` or
> `-p` outputs, despite the user explicitly requesting to ignore certain
> changes using `-I<regex>`. To provide this consistency, Introduces
> the diffcore_ignore() function in the new diffcore-ignore.c file, which
> removes changes matching `-I<regex>`, and call diffcore_ignore() in
> diffcore_std().
>
> This patch ensures that the behavior of `-I<regex>` is applied
> consistently across multiple diff output formats (`--name-only`,
> `--name-status`, `--stat`, and `-p`). Only `--raw` and `--check` will
> ignore `-I<regex>` and retain the original output.
>
> Signed-off-by: Lidong Yan <yldhome2d2@xxxxxxxxx>
> ---
> Makefile | 1 +
> diff.c | 2 +
> diffcore-ignore.c | 152 ++++++++++++++++++++++++++++++++++++++++
> diffcore.h | 1 +
> t/t4013-diff-various.sh | 57 ++++++++++++++-
> 5 files changed, 211 insertions(+), 2 deletions(-)
> create mode 100644 diffcore-ignore.c
The enthusiasm is appreciated, but the implementation raises two
questions.
* This special cases -I<pattern>, but any option that causes us to
set the .diff_from_contents flag, not just -I<pattern>, can cause
the raw blob comparison to be potentially different from what the
blob contents are compared with various "ignore this class of
changes" criteria. Shouldn't "git diff -w --name-status" and the
like get the same treatment?
* Also, should we internally run diff twice, especially even when
we are going to show the patch output and are not limited to
FORMAT_NAME and FORMAT_NAME_STATUS? Generally, running the real
diff in any of the diffcore transformatin is a sign of trouble.
Also, the usual way to compose a log message of this project is to
- Give an observation on how the current system works in the
present tense (so no need to say "Currently X is Y", or
"Previously X was Y" to describe the state before your change;
just "X is Y" is enough), and discuss what you perceive as a
problem in it.
- Propose a solution (optional---often, problem description
trivially leads to an obvious solution in reader's minds).
- Give commands to somebody editing the codebase to "make it so",
instead of saying "This commit does X".
in this order.
