patchgit-submodule.txt: fix AsciiDoc formatting error

In b57e8119e6 (submodule: teach set-branch subcommand, 2019-02-08), the `set-branch` subcommand was added for submodules. When the documentation was written, the syntax for a "index term" in AsciiDoc was accidentally used. This caused the documentation to be rendered as

	set-branch -d|--default)|(-b|--branch <branch> [--] <path>

instead of

	set-branch (-d|--default)|(-b|--branch <branch>) [--] <path>

Remove surrounding parentheses so that the "index term" syntax is not triggered (and because it looks nicer without them anyway ;) ).

Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
 Documentation/git-submodule.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Denton Liu <liu.denton@gmail.com> writes:

"Correct" always trumps "nicer", though ;-)

The $USAGE string in the script describes the available options to this subcommand like so:

    or: $dashless [--quiet] set-branch (--default|--branch <branch>) [--] <path>

which is, "you can give either --default or --branch <branch>, but not both". What the original, if there were no special meaning in double-paren, meant to say seems to (almost) match that.

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?

I think the attempt to cram the short-form is unnecessarily cluttering and making the result incorrect. How about doing something like this instead?

 Documentation/git-submodule.txt | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

On Fri, Sep 13, 2019 at 11:03:39AM -0700, Junio C Hamano wrote:

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. With this change, a reader would have to not only read the summary line but also scan the blurb below.

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.

Denton Liu <liu.denton@gmail.com> writes:

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.

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).

In b57e8119e6 (submodule: teach set-branch subcommand, 2019-02-08), the `set-branch` subcommand was added for submodules. When the documentation was written, the syntax for a "index term" in AsciiDoc was accidentally used. This caused the documentation to be rendered as

	set-branch -d|--default)|(-b|--branch <branch> [--] <path>

instead of

	set-branch ((-d|--default)|(-b|--branch <branch>)) [--] <path>

In addition to this, the original documentation was possibly confusing as it made it seem as if the `-b` option didn't accept a `<branch>` argument.

Break `--default` and `--branch` into their own separate invocations to make it obvious that these options are mutually exclusive. Also, this removes the surrounding parentheses so that the "index term" syntax is not triggered.

Signed-off-by: Denton Liu <liu.denton@gmail.com>
---

Thanks for reviewing, Junio.

I thought about it over the weekend and I hope that this is a good compromise.

I looked through other options in the documentation and I couldn't find any other places where a short-form was documented in the body instead of in the summary line so I didn't want to introduce that with this commit. I feel like it would be unfamiliar to someone who's used to reading other Git documentation.

Also, I opted to separate the the options onto their own lines because this makes it obvious that these two arguments are incompatible. Hopefully, this assuages your concerns.

Range-diff against v1:
1:  796a25ee1e ! 1:  2ae16375ba git-submodule.txt: fix AsciiDoc formatting error
    @@ Commit message
     
         instead of
     
    -            set-branch (-d|--default)|(-b|--branch <branch>) [--] <path>
    +            set-branch ((-d|--default)|(-b|--branch <branch>)) [--] <path>
     
    -    Remove surrounding parentheses so that the "index term" syntax is not
    -    triggered (and because it looks nicer without them anyway ;) ).
    +    In addition to this, the original documentation was possibly confusing
    +    as it made it seem as if the `-b` option didn't accept a `<branch>`
    +    argument.
    +
    +    Break `--default` and `--branch` into their own separate invocations to
    +    make it obvious that these options are mutually exclusive. Also, this
    +    removes the surrounding parentheses so that the "index term" syntax is
    +    not triggered.
     
         Signed-off-by: Denton Liu <liu.denton@gmail.com>
     
    @@ Documentation/git-submodule.txt: submodule with the `--init` option.
      registered submodules, and update any nested submodules within.
      --
     -set-branch ((-d|--default)|(-b|--branch <branch>)) [--] <path>::
    -+set-branch (-d|--default)|(-b|--branch <branch>) [--] <path>::
    ++set-branch (-b|--branch) <branch> [--] <path>::
    ++set-branch (-d|--default) [--] <path>::
      	Sets the default remote tracking branch for the submodule. The
      	`--branch` option allows the remote branch to be specified. The
      	`--default` option removes the submodule.<name>.branch configuration

 Documentation/git-submodule.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Denton Liu <liu.denton@gmail.com> writes:

That sounds even clearer than what the original wanted to do. Very good idea.