On 02/06 09:45, Christian Couder wrote: > > > > I'm having second thoughts about my suggestion[1] to include > > the short option for '--quiet' in the usage. This is the only > > usage in submodule--helper that mentions that '-q' is a short > > hand for '--quiet'. That seems inconsistent. I see two ways but > > I'm not sure which one of these would be better: > > > > A. Dropping the mention of '-q' in this usage thus making it consistent > > with the other usages printed by submodule--helper. > > > > B. Fixing other usages of submodule--helper to mention that '-q' is > > shorthand for quiet. This has the benefit of properly advertising > > the shorthand. > > > > C. Just ignore this? > > The `git submodule` documentation has: > > -q:: > --quiet:: > Only print error messages. > > even though the Synopsis is: > > 'git submodule' [--quiet] [--cached] > 'git submodule' [--quiet] add [<options>] [--] <repository> [<path>] > 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...] > ... > > So I prefer B, and maybe updating the synopsis, as I think most Git > commands have '-q' meaning '--quiet'. Yep, (B) sounds good! Junio in one of the previous mails stated that this thing will need to be done for all subcommands when the shell script is to be demolished i.e., `git submodule` becomes a builtin completely. Actually, vrious usages might need to be fixed, for many subcommands because almost none of them have any info about the shorthand usages of options in their `options` array.