Denton Liu <liu.denton@xxxxxxxxx> writes: >> > -set-branch ((-d|--default)|(-b|--branch <branch>)) [--] <path>:: >> >> I say "almost", as it gives a wrong impression that you can give >> "-b" without "<branch>" X-<. >> >> Now what does the updated text say to us? >> >> > +set-branch (-d|--default)|(-b|--branch <branch>) [--] <path>:: >> >> I think the attempt to cram the short-form is unnecessarily >> cluttering and making the result incorrect. >> ... >> > Hmm, I don't really like this since with every other subcommand, the > short-forms are in the command summary so it's obvious to the reader > in a quick glance which options are available. I actually do not think it adds that much value. Once a user learns what --branch does and is told -b is its short form, it is much less important that -b and --branch are both available than --default and --branch are possibilities, and you cannot use both at the same time. If anything, perhaps other subcommands' description may benefit if we unclutter by reducing the prominence we give to their short form. > In the context line above, we see `[(-n|--summary-limit) <n>]` as a > possible way of notating a short and long option with argument. What do > you think about the following potential output? > > set-branch (-d|--default)|((-b|--branch) <branch>) [--] <path>:: > > Of course, we reintroduce the double paren problem but I can dig into > asciidoc syntax and figure out how to escape it properly. That's much less important than the fact that you are losing "-b and -d cannot be used together", which is what the usage string gives us (and which is what I tried to express with my rewrite).
