Re: [PATCH 0/7] Flags and config to sign pushes by default

From: Dave Borowitz <dborowitz@google.com>
Date: Aug 17, 2015, 18:32 UTC
Message-ID: <CAD0k6qTWojeWT10xw_Dc5=Fw5r3rP0PUQOyqO7JAz6Vu+tV54w@mail.gmail.com>
In-Reply-To: <xmqqtwrxesqa.fsf@gitster.dls.corp.google.com>

On Mon, Aug 17, 2015 at 1:21 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 29 quoted lines

> Dave Borowitz <dborowitz@google.com> writes:
>
>> Ok, so let us bikeshed a bit further.
>>
>> Bikeshed 1.
>> Option A: --signed/--no-signed--signed-if-possible
>> Option B: --signed=true|false|if-possible, "--signed" alone implies "=true".
>>
>> Bikeshed 2.
>>
>> Option A: if-possible
>>
>> The possibly confusing thing is one might interpret missing "gpg" to
>> mean "impossible", i.e. "if gpg is not installed don't attempt to
>> sign", which is not the behavior we want.
>>
>> I don't have another succinct way of saying this.
>> "if-server-supported" is a mouthful. I think Jonathan mentioned
>> "opportunistic", which is fairly opaque.
>>
>>> By "strange", I was referring to the possible perception issue on
>>> having a choice other than yes/no for a configuration that allows
>>> you to express your security preference.
>
> My preference on Bikeshed 1. would probably be to add
>
>     --sign=yes/no/if-asked
>
> and to keep --[no-]signed for "no" and "yes" for existing users.

Incidentally, I just looked up incidence of true/false vs. yes/no in command line options, and the results are decidedly undecided:

$ grep -e '--[^ ]*=[^ ]*true' Documentation/*.txt Documentation/git-init.txt:--shared[=(false|true|umask|group|all|world|everybody|0xxx)]:: Documentation/git-pull.txt:--rebase[=false|true|preserve]:: Documentation/git-svn.txt:--shared[=(false|true|umask|group|all|world|everybody)]:: $ grep -e '--[^ ]*=[^ ]*yes' Documentation/*.txt Documentation/fetch-options.txt:--recurse-submodules[=yes|on-demand|no]:: Documentation/fetch-options.txt:--recurse-submodules-default=[yes|on-demand]:: Documentation/git-pull.txt:--[no-]recurse-submodules[=yes|on-demand|no]::

Consistency is hard.

I am inclined to stick with yes/no in this case because --recurse-submodules at least feels like a more modern option that we should emulate, but don't feel strongly either way.

> Regarding Bikeshed 2., I do not have a strong opinion myself.

Although it sounds like you already expressed an opinion for if-asked

> if-possible, which is stronger than my own :)

> Thanks.