On Tue, Sep 5, 2017 at 8:16 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Junio C Hamano <gitster@xxxxxxxxx> writes:
>
>> Stefan Beller <sbeller@xxxxxxxxxx> writes:
>>
>>> This patch disallows all no- options, but we could be more open and allow
>>> --no-options that have the NO_NEG bit set.
>>
>> "--no-foo" that does not take "--foo" is perhaps OK so should not
>> trigger an error.
>>
>> A ("--no-foo", "--foo") pair is better spelled as ("--foo",
>> "--no-foo") pair whose default is "--foo", but making it an error is
>> probably a bit too much.
>>
>> Compared to that, ("--no-foo", "--no-no-foo") pair feels nonsense.
>
> Ahh, I was an idiot (call it vacation-induced-brain-disfunction). I
> forgot about 0f1930c5 ("parse-options: allow positivation of options
> starting, with no-", 2012-02-25), which may have already made your
> new use of "--no-verify" in builtin/merge.c and existing one in
> commit.c OK long time ago. A quick check to see how your version of
>
> git merge --verify
> git merge --no-verify
>
> behaves with respect to the commit-msg hook is veriy much
> appreciated, as my tree is in no shape to apply and try a patch
> while trying to absorb the patches sent to the list the past week.
>
> Thanks, and sorry for a possible false alarm.
>
>> Having said that, because the existing parse_options_check() is all
>> about catching the programming mistake (the end user cannot fix an
>> error from it by tweaking the command line option s/he gives to the
>> program), I do not think a conditional compilation like you added
>> mixes well. Either make the whole thing, not just your new test,
>> conditional to -DDEVELOPER (which would make it possible for you to
>> build and ship a binary with broken options[] array to the end-users
>> that does not die in this function), which is undesirable, or add a
>> new test that catches a definite error unconditionally.
>
> This part still is valid. If René's work 2 years ago is sufficient
> to address "--no-foo" thing, then there is nothing we need to add to
> this test, but if we later need to add new sanity check, we should
> add it without -DDEVELOPER, or we should make the whole thing inside
> it.
As far as the code is concerned it is only inside the -DDEVELOPER ?
The intent of this patch is to have a developers aid to remind them
that too many negations might be a sign of trouble.
Thanks,
Stefan
>
> Thanks.
