Subject: Re: Unexpected behavior on diff -I<regex> --name-only

From: Junio C Hamano <[email-masked]>
Date: Mon, 14 Dec 2020 11:49:06 -0800

Johannes Altmanninger <[email-masked]> writes:

> Since v2.28.0-2-g296d4a94e7 (diff: add -I<regex> that ignores matching changes)
> diff -I<regex> can be used to suppress hunks of only matching lines.
> This interacts in a surprising way with --name-only, which lists
> all changed files, regardless of whether they are filtered out by -I<regex>:
>
> 	git diff HEAD~ -I ''			# always empty
> 	git diff HEAD~ -I '' --name-only	# not empty, "-I" does nothing
>
> It could be nice to only show names of files with matching hunks
> (or reject this combination of options?).

Interesting.  

This is not a new issue limited to -I at all.  If you did this:

	$ echo "hello" >world
	$ git add world ; git commit -m 'add world'
	$ echo " hello" >world ; git add world
	$ git diff -w --cached
	$ git diff --name-only --cached
	world
	$ git diff --name-only -w --cached
	world

I think "--name-only", and perhaps other options, has too aggressive
an optimization that takes advantage of the fact that we can tell if
a path has changed or not without looking at the contents at all by
looking at the object name recorded.  That optimization may have
been valid until many newer and more expensive features came around,
but not anymore.

I think diff.c::flush_one_pair() needs to learn to pay attention to
opt->diff_from_contents in its third branch where DIFF_FORMAT_NAME
is handled.  I do not offhand remember if -I flips diff_from_contents
bit, but I wouldn't be surprised if the recent change added the
support for -I forgot to do so.

Thanks.