On 07/17/2013 07:04 PM, Junio C Hamano wrote:

> Builtins link all sorts of stuff from outside, e.g. diff.c and
> diffcore-*.c at the toplevel.  I do not see diff_no_index.c is any
> different, so I am probably not understanding your question.

Thanks for the explanation. I am not yet very used to gits code structure. So I sometimes think of 'how would I structure things', so I
was confused of things in builtin using some parts outside of it.
Maybe that folder raised to much expectations for me to be 'the real'
core, whereas the files outside, i.e. those files in the top level
directory, are just there for other things or scripts.
This understanding of the structure seems obviously wrong now.

Thanks for clarification.

> 
> Hmm, do you really get that error message?  I think you would get
> 
>     fatal: ambiguous argument 'no_file': unknown revision or path not in the working tree.
> 
>> 	echo $?
>> 	1

Ok here we go (using current origin/master 9c3c367):

	cd $(mktemp -d)
	echo "test" > actual_file
	git diff actual_file no_file
	# error: Could not access 'no_file'
	echo $?
	1
	
	## I get the same message as well, if I'm using -- or not.
	## also the -q doesn't make a change

	git init 
	git diff -q -- actual_file no_file
	echo $?
	# 0
	git diff  -- actual_file no_file
	echo $?
	# 0
	git diff  actual_file no_file
	# fatal: no_file: no such path in the working tree.
	# Use 'git <command> -- <path>...' to specify paths that do not exist locally.
	echo $?
	# 128
	git diff -q  actual_file no_file
	# fatal: no_file: no such path in the working tree.
	# Use 'git <command> -- <path>...' to specify paths that do not exist locally.
	echo $?
	128

So apparently git diff behaves differently if not in a repo, which is what I tested.

> 
> The command line parsing infrastructure has changed vastly since
> "show-diff" days (see below for a history lesson);

A very interesting read, much appreciated. :)

> 
> If we wanted to make "-q" follow the spirit of its original addition
> to "show-diff" again, we could internally add a diff-filter when the
> "-q" option is parsed.
> 

I'm rather new to the project, so my opinion may not have much weight,
I'll state it anyway:
Keeping backwards compatibility is really hard, because you need the 
knowledge of such history lessons as read above, to understand what should
happen, like having an intuitive feeling about such parameters. Hence
maintaining/evolving the project will become harder and harder 
(specially for newcomers). So having one and only one way to achieve the desired
output, which fits into the greater structure as it's the case with --diff-filter
is easier to remember for both the user and developers.

Hence I think keeping the -q option would only make sense for the plumber 
layer, because there the explicit promise was given to not change stuff
every other release. 

Stefan