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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Altmanninger <aclopte@xxxxxxxxx> 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.












[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux