osc buildinfo --help text raises a question (regarding BUILD_DESCR) that it doesn't answer

[smithfarm]

Describe the bug

$ osc buildinfo --help
usage: osc [global opts] buildinfo [-h] [--alternative-project PROJECT] [-d]
                                   [-M FLAVOR] [-x PAC] [-p DIR]

Shows the build "info" which is used in building a package.
This command is mostly used internally by the 'build' subcommand.
It needs to be called from within a package directory.

The BUILD_DESCR argument is optional. BUILD_DESCR is a local RPM specfile
or Debian "dsc" file. If specified, it is sent to the server, and the
buildinfo will be based on it. If the argument is not supplied, the
buildinfo is derived from the specfile which is currently on the source
repository server.

The reader encounters BUILD_DESCR here and fails to find it in the "usage" (syntax description).

Further, if osc buildinfo does indeed accept such an argument, I suggest to reconsider the name "BUILD_DESCR". The OBS documentation uses the term "build recipe" as a general term to refer to spec/dsc/etc. files, not "build description". So maybe "BUILD_RECIPE" would be a better choice here?

Versions
osc-1.6.1-150400.403.1.noarch

To Reproduce
Steps to reproduce the behavior:

1. Run command osc buildinfo --help
2. See confusing output

Expected behavior
The arguments that appear in the "usage" (syntax description) should be described in more detail in the description that follows. This is satisfied. Also, the description should not describe any arguments that do not appear in the "usage". This is not satisfied.

[smithfarm]

I see now that the BUILD_DESCR argument is described in the second usage block, which appears further down in the help text. This is bad style, however. One way would be to have a single usage block at the top, but that's not the only option. Another way would be to break up the description text like so:

<usage block 1>
<text describing the arguments appearing in usage block 1>
<usage block 2>
<text describing the arguments appearing in usage block 2>

Right now we have:

<usage block 1>
<text describing the arguments appearing in usage block 1 and usage block 2 (!)>
<usage block 2>