подбираем и массируем параметры (Pick out and massage parameters)
PARSEOPT
In --parseopt mode, git rev-parse helps massaging options to
bring to shell scripts the same facilities C builtins have. It
works as an option normalizer (e.g. splits single switches
aggregate values), a bit like getopt(1) does.
It takes on the standard input the specification of the options
to parse and understand, and echoes on the standard output a
string suitable for sh(1) eval to replace the arguments with
normalized ones. In case of error, it outputs usage on the
standard error stream, and exits with code 129.
Note: Make sure you quote the result when passing it to eval. See
below for an example.
Input Format
git rev-parse --parseopt input format is fully text based. It has
two parts, separated by a line that contains only --. The lines
before the separator (should be one or more) are used for the
usage. The lines after the separator describe the options.
Each line of options has this format:
<opt-spec><flags>*<arg-hint>? SP+ help LF
<opt-spec>
its format is the short option character, then the long
option name separated by a comma. Both parts are not
required, though at least one is necessary. May not contain
any of the <flags> characters. h,help, dry-run and f are
examples of correct <opt-spec>.
<flags>
<flags> are of *, =, ? or !.
• Use = if the option takes an argument.
• Use ? to mean that the option takes an optional
argument. You probably want to use the --stuck-long mode
to be able to unambiguously parse the optional argument.
• Use * to mean that this option should not be listed in
the usage generated for the -h argument. It's shown for
--help-all as documented in gitcli(7).
• Use ! to not make the corresponding negated long option
available.
<arg-hint>
<arg-hint>, if specified, is used as a name of the argument
in the help output, for options that take arguments.
<arg-hint> is terminated by the first whitespace. It is
customary to use a dash to separate words in a multi-word
argument hint.
The remainder of the line, after stripping the spaces, is used as
the help associated to the option.
Blank lines are ignored, and lines that don't match this
specification are used as option group headers (start the line
with a space to create such lines on purpose).
Example
OPTS_SPEC="\
some-command [<options>] <args>...
some-command does foo and bar!
--
h,help show the help
foo some nifty option --foo
bar= some cool option --bar with an argument
baz=arg another cool option --baz with a named argument
qux?path qux may take a path argument but has meaning by itself
An option group Header
C? option C with an optional argument"
eval "$(echo "$OPTS_SPEC" | git rev-parse --parseopt -- "$@" || echo exit $?)"
Usage text
When "$@" is -h or --help in the above example, the following
usage text would be shown:
usage: some-command [<options>] <args>...
some-command does foo and bar!
-h, --help show the help
--foo some nifty option --foo
--bar ... some cool option --bar with an argument
--baz <arg> another cool option --baz with a named argument
--qux[=<path>] qux may take a path argument but has meaning by itself
An option group Header
-C[...] option C with an optional argument
