On Mon, Aug 17, 2015 at 2:47 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Dave Borowitz <dborowitz@xxxxxxxxxx> writes: > >> On Mon, Aug 17, 2015 at 1:21 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> >>> 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,... > > My yes/no was a short-hand for "yes" (and various other ways to > spell "true") and "no" (and various other ways to spell "false"). I > was NOT bikeshedding to say "I do not like true/false but favor > yes/no". > > I actually was expecting a short discussion on sign vs signed, > though. As "tag --sign" is not "tag --signed" even though we call > the resulting object a "signed tag", "push --sign" may be a good > enough way to spell "signed push". I _think_ signed pushes are > recent enough that we still have time to deprecate --signed form, > but I do not think it is worth it. I agree that "push --sign" would be better than "push --signed" for consistency with tag, but will defer to you as to whether it's worth it to do the deprecation. > So an updated suggestion would be that we'd take (this is a pretty > much exhaustive enumeration) these: > > --no-signed > --signed > --signed=if-asked > --signed=yes/true/on/1/2... > --signed=no/false/off/0 Fine by me. Would you expect those to all be documented, or just --[no-]signed|--signed=(yes|no|if-asked) and silently accept the rest? Is there a common utility function that does what we want? Basically git_config_maybe_bool but not specifically about configs. > We might want to throw in 'always' and 'never' as synonyms for > 'true' and 'false', but again I do not think it is worth the > confusion factor, as 'always' and 'true' already mean different > things in some other contexts. > > Thanks. > > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html