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

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 14, 2020, 19:49 UTC
Message-ID: <xmqqeejsdv7x.fsf@gitster.c.googlers.com>
In-Reply-To: <20201214190054.lrdllbpf6jfrz573@gmail.com>

Johannes Altmanninger <aclopte@gmail.com> writes:

Show 10 quoted lines

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