Dave Borowitz [off-list ref] 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.
quoted
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.
Regarding Bikeshed 2., I do not have a strong opinion myself.
Thanks.
On Mon, Aug 17, 2015 at 1:21 PM, Junio C Hamano [off-list ref] wrote:
Dave Borowitz [off-list ref] writes:
quoted
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.
quoted
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.