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
Attachment:
signature.asc
Description: OpenPGP digital signature