Re: [PATCH 3/3] builtin/grep: allow implicit --no-index

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 11, 2016, 19:35 UTC
Message-ID: <xmqqmvsbx62d.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160111192844.GD10612@hank>

Thomas Gummerer <t.gummerer@gmail.com> writes:

Show 16 quoted lines

>> > +#define GREP_NO_INDEX_EXPLICIT 1
>> > +#define GREP_NO_INDEX_IMPLICIT 2
>>
>> I am not sure this is the best way to do this.  For things like
>> this, the usual pattern is to initialize "no_index" to an "unknown"
>> value, allow "--no-index" to toggle it to true (by the way, I think
>> we should reject "--no-no-index", but that is a separate topic), and
>> then after command line parsing finishes, tweak the no_index if it
>> is still "unknown".
>
> The reason for this (and the change in 02/03) is so we can distinguish
> whether there is an explicit no-index or not for the error messages.
> I think it would be okay to have more generic error messages
> ("--cached or --untracked cannot be used without index" and
> "--untracked or no index mode cannot be used with revs").  What do you
> think?

I can understand that you need three states (--no-index given explicitly from the command line, we fall back to --no-index when we found we are in a diretory not under control by Git, and we do want to use the index) to be able to give different messages between the first two cases.

The usual way we do that is by making the variable tristate (which I outlined in the previous message, initialize use_index to -1 "unspecified" and then fix it up when it is left unspecified after you check the config and the command line option).

I however fail to see why that necessitates to change use_index to no_index, making the code harder to follow by introducing double negation.