+
If you want to make sure that the output actually names an object in
your object database and/or can be used as a specific type of object
-you require, you can add "^{type}" peeling operator to the parameter.
+you require, you can add "\^{type}" peeling operator to the parameter.
For example, `git rev-parse "$VAR^{commit}"` will make sure `$VAR`
names an existing object that is a commit-ish (i.e. a commit, or an
annotated tag that points at a commit). To make sure that `$VAR`
Each line of options has this format:
------------
-<opt_spec><flags>*<arg_hint>? SP+ help LF
+<opt-spec><flags>*<arg-hint>? SP+ help LF
------------
-`<opt_spec>`::
+`<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. `h,help`, `dry-run` and `f` are all three correct
- `<opt_spec>`.
+ `<opt-spec>`.
`<flags>`::
`<flags>` are of `*`, `=`, `?` or `!`.
* 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. When you need to use space in the
- argument hint use dash instead.
+`<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.
-h, --help show the help
--foo some nifty option --foo
--bar ... some cool option --bar with an argument
- --bar <arg> another cool option --baz with a named 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