| Message ID | ba624c59-5330-360e-dc4a-432752d22fc1@web.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | parse-options: document automatic PARSE_OPT_LITERAL_ARGHELP | expand |
On Wed, Jan 19 2022, René Scharfe wrote: > The help strings for arguments are enclosed in angle brackets > automatically. E.g. if argh is specified as "name", "--option <name>" > is printed, to indicate that users need to supply an actual name. The > flag PARSE_OPT_LITERAL_ARGHELP turns this off, so that "--option name" > is printed instead, to indicate that the literal string needs to be > supplied -- a rare case. > > This flag is enabled automatically if argh contains special characters > like brackets. The developer is supposed to provide any required angle > brackets for more complicated cases. E.g. if argh is "<start>,<end>" > then "--option <start>,<end>" is printed. > > Add a comment to mention this PARSE_OPT_LITERAL_ARGHELP behavior. > > Also remove the flag from option definitions for which it's inferred > automatically. > > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > Somehow I feel this is not enough, but I can't pin down what's > missing. Rather than just remove the flag from {am,push}.c and document this it would be better to add it to the optbug() checks in parse_options_check(). That way we'll ensure that these flags won't be redunantly specified, if we care enough...
Am 19.01.22 um 16:15 schrieb Bryce Ekrem: > Can you clarify what argh is instead of argc and argv > sounds like you said arghelp argh is a member of struct option, defined in parse-options.h. It is a string that describes the argument of an option, i.e. it's a short "argument help" or "argument hint". > On Wed, Jan 19, 2022 at 2:57 AM René Scharfe <l.s.r@web.de <mailto:l.s.r@web.de>> wrote: > > The help strings for arguments are enclosed in angle brackets > automatically. E.g. if argh is specified as "name", "--option <name>" > is printed, to indicate that users need to supply an actual name. The > flag PARSE_OPT_LITERAL_ARGHELP turns this off, so that "--option name" > is printed instead, to indicate that the literal string needs to be > supplied -- a rare case. > > This flag is enabled automatically if argh contains special characters > like brackets. The developer is supposed to provide any required angle > brackets for more complicated cases. E.g. if argh is "<start>,<end>" > then "--option <start>,<end>" is printed. > > Add a comment to mention this PARSE_OPT_LITERAL_ARGHELP behavior. > > Also remove the flag from option definitions for which it's inferred > automatically. > > Signed-off-by: René Scharfe <l.s.r@web.de <mailto:l.s.r@web.de>> > --- > Somehow I feel this is not enough, but I can't pin down what's > missing. > > builtin/am.c | 2 +- > builtin/push.c | 2 +- > parse-options.h | 2 ++ > 3 files changed, 4 insertions(+), 2 deletions(-) > > diff --git a/builtin/am.c b/builtin/am.c > index b6be1f1cb1..fa8d28794a 100644 > --- a/builtin/am.c > +++ b/builtin/am.c > @@ -2402,7 +2402,7 @@ int cmd_am(int argc, const char **argv, const char *prefix) > { OPTION_CALLBACK, 0, "show-current-patch", &resume.mode, > "(diff|raw)", ^^^^^^^^^^^^ This is the argh for that particular option (--show-current-patch). > N_("show the patch being applied"), > - PARSE_OPT_CMDMODE | PARSE_OPT_OPTARG | PARSE_OPT_NONEG | PARSE_OPT_LITERAL_ARGHELP, > + PARSE_OPT_CMDMODE | PARSE_OPT_OPTARG | PARSE_OPT_NONEG, > parse_opt_show_current_patch, RESUME_SHOW_PATCH }, > OPT_CMDMODE(0, "allow-empty", &resume.mode, > N_("record the empty patch as an empty commit"), > diff --git a/builtin/push.c b/builtin/push.c > index 359db90321..4fa6dfbd09 100644 > --- a/builtin/push.c > +++ b/builtin/push.c > @@ -552,7 +552,7 @@ int cmd_push(int argc, const char **argv, const char *prefix) > OPT_BIT('f', "force", &flags, N_("force updates"), TRANSPORT_PUSH_FORCE), > OPT_CALLBACK_F(0, CAS_OPT_NAME, &cas, N_("<refname>:<expect>"), ^^^^^^^^^^^^^^^^^^^^^^^^ And here's the one for CAS_OPT_NAME, defined elsewhere, (resolves to --force-with-lease). > N_("require old value of ref to be at this value"), > - PARSE_OPT_OPTARG | PARSE_OPT_LITERAL_ARGHELP, parseopt_push_cas_option), > + PARSE_OPT_OPTARG, parseopt_push_cas_option), > OPT_BIT(0, TRANS_OPT_FORCE_IF_INCLUDES, &flags, > N_("require remote updates to be integrated locally"), > TRANSPORT_PUSH_FORCE_IF_INCLUDES), > diff --git a/parse-options.h b/parse-options.h > index e22846d3b7..8d089fb3ae 100644 > --- a/parse-options.h > +++ b/parse-options.h Here's the comment about argh from parse-options.h: * `argh`:: * token to explain the kind of argument this option wants. Does not * begin in capital letter, and does not end with a full stop. * Should be wrapped by N_() for translation. > @@ -108,6 +108,8 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, > * PARSE_OPT_LITERAL_ARGHELP: says that argh shouldn't be enclosed in brackets > * (i.e. '<argh>') in the help message. > * Useful for options with multiple parameters. > + * Automatically enabled if argh contains any > + * of the following characters: ()<>[]| > * PARSE_OPT_NOCOMPLETE: by default all visible options are completable > * by git-completion.bash. This option suppresses that. > * PARSE_OPT_COMP_ARG: this option forces to git-completion.bash to > -- > 2.34.1 >
René Scharfe <l.s.r@web.de> writes: > The help strings for arguments are enclosed in angle brackets > automatically. E.g. if argh is specified as "name", "--option <name>" > is printed, to indicate that users need to supply an actual name. The > flag PARSE_OPT_LITERAL_ARGHELP turns this off, so that "--option name" > is printed instead, to indicate that the literal string needs to be > supplied -- a rare case. > > This flag is enabled automatically if argh contains special characters > like brackets. The developer is supposed to provide any required angle > brackets for more complicated cases. E.g. if argh is "<start>,<end>" > then "--option <start>,<end>" is printed. The above does explain why we want to have this change very well, but at least some of it would help those who are reading the comment we touch. > Add a comment to mention this PARSE_OPT_LITERAL_ARGHELP behavior. But instead, the addition is only about when the flag bit is turned on automatically. Without understanding your E.g. if argh is specified as "name", "--option <name>" is printed, to indicate that users need to supply an actual name. readers would not quite get from the current description "says that argh shouldn't be enclosed in brackets" when/why it is a good idea to add the option, I am afraid. > Also remove the flag from option definitions for which it's inferred > automatically. I am not sure if this is a good move. Because these places explicitly gave PARSE_OPT_LITERAL_ARGHELP, it was easy to grep for them when I was trying to find an existing practice. Imagine, after we remove these redundant flags, we see a patch that wants to change the set of characters that automatically flips the flag bit on. It is clear from the patch text why it helps one particular OPT_STRING() or whatever the same patch adds, but how would you make sure it will not regress _existing_ OPT_WHATEVER() that do not use PARSE_OPT_LITERAL_ARGHELP because their argh happens to use the character that wasn't special before? > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > Somehow I feel this is not enough, but I can't pin down what's > missing. Let me try. > * PARSE_OPT_LITERAL_ARGHELP: says that argh shouldn't be enclosed in brackets > * (i.e. '<argh>') in the help message. > * Useful for options with multiple parameters. > + * Automatically enabled if argh contains any > + * of the following characters: ()<>[]| > * PARSE_OPT_NOCOMPLETE: by default all visible options are completable > * by git-completion.bash. This option suppresses that. > * PARSE_OPT_COMP_ARG: this option forces to git-completion.bash to PARSE_OPT_LITERAL_ARGHELP: in short-help given by "git cmd -h", the "argh" member of the struct option is shown in a pair of angle brackets (e.g. "--option=<argh>"); this flag tells the machinery not to add these brackets, to give more control to the developer. E.g. "<start>,<end>" given to argh is shown as "--option=<start>,<end>". That may be a bit too much, but on the other hand, among PARSE_OPT_X descriptions, this is the only one that needs to talk about help text on the argument to the option. Or we can flip it the other way, perhaps? Tell the machinery to give "argh" member literally in the short-help in "git cmd -h" output for the option. E.g. { .argh = "(diff|raw)", .long_name = "show" } would give "--show=(diff|raw)". Without the flag, "argh" is enclosed in a pair of angle brackets. I dunno.
Am 19.01.22 um 19:16 schrieb Junio C Hamano: > René Scharfe <l.s.r@web.de> writes: > >> The help strings for arguments are enclosed in angle brackets >> automatically. E.g. if argh is specified as "name", "--option <name>" >> is printed, to indicate that users need to supply an actual name. The >> flag PARSE_OPT_LITERAL_ARGHELP turns this off, so that "--option name" >> is printed instead, to indicate that the literal string needs to be >> supplied -- a rare case. >> >> This flag is enabled automatically if argh contains special characters >> like brackets. The developer is supposed to provide any required angle >> brackets for more complicated cases. E.g. if argh is "<start>,<end>" >> then "--option <start>,<end>" is printed. > > The above does explain why we want to have this change very well, > but at least some of it would help those who are reading the comment > we touch. > >> Add a comment to mention this PARSE_OPT_LITERAL_ARGHELP behavior. > > But instead, the addition is only about when the flag bit is turned > on automatically. Without understanding your > > E.g. if argh is specified as "name", "--option <name>" is > printed, to indicate that users need to supply an actual name. > > readers would not quite get from the current description "says that > argh shouldn't be enclosed in brackets" when/why it is a good idea > to add the option, I am afraid. > >> Also remove the flag from option definitions for which it's inferred >> automatically. > > I am not sure if this is a good move. > > Because these places explicitly gave PARSE_OPT_LITERAL_ARGHELP, it > was easy to grep for them when I was trying to find an existing > practice. > > Imagine, after we remove these redundant flags, we see a patch that > wants to change the set of characters that automatically flips the > flag bit on. It is clear from the patch text why it helps one > particular OPT_STRING() or whatever the same patch adds, but how > would you make sure it will not regress _existing_ OPT_WHATEVER() > that do not use PARSE_OPT_LITERAL_ARGHELP because their argh happens > to use the character that wasn't special before? Building a multi-line regex or going through the output of --help-all of all commands or adding a throwaway internal option to just print argh would certainly be much harder. Reducing the set of special characters would be part of a change to the notation for describing options. Perhaps we'd want to no longer use grouping and thus get rid of parentheses. That would require updating all affected manpages and usage strings as well -- quite a big effort, regardless of PARSE_OPT_LITERAL_ARGHELP's grepability. Extending the set, e.g. to give special meaning to curly brackets, can't rely on the explicit flag; all argh strings need to be examined to check whether they become special. > >> Signed-off-by: René Scharfe <l.s.r@web.de> >> --- >> Somehow I feel this is not enough, but I can't pin down what's >> missing. > > Let me try. > >> * PARSE_OPT_LITERAL_ARGHELP: says that argh shouldn't be enclosed in brackets >> * (i.e. '<argh>') in the help message. >> * Useful for options with multiple parameters. >> + * Automatically enabled if argh contains any >> + * of the following characters: ()<>[]| >> * PARSE_OPT_NOCOMPLETE: by default all visible options are completable >> * by git-completion.bash. This option suppresses that. >> * PARSE_OPT_COMP_ARG: this option forces to git-completion.bash to > > PARSE_OPT_LITERAL_ARGHELP: in short-help given by "git cmd -h", the > "argh" member of the struct option is > shown in a pair of angle brackets (e.g. > "--option=<argh>"); this flag tells the > machinery not to add these brackets, to > give more control to the developer. E.g. > "<start>,<end>" given to argh is shown as > "--option=<start>,<end>". > > That may be a bit too much, but on the other hand, among PARSE_OPT_X > descriptions, this is the only one that needs to talk about help > text on the argument to the option. > > Or we can flip it the other way, perhaps? > > Tell the machinery to give "argh" member literally in the > short-help in "git cmd -h" output for the option. E.g. { > .argh = "(diff|raw)", .long_name = "show" } would give > "--show=(diff|raw)". Without the flag, "argh" is enclosed > in a pair of angle brackets. > > I dunno. Now that I read the whole comment, I think the right place to introduce the automatic brackets is the description of argh some lines up. --- >8 --- Subject: [PATCH 5/5] parse-options: document bracketing of argh Signed-off-by: René Scharfe <l.s.r@web.de> --- parse-options.h | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/parse-options.h b/parse-options.h index e22846d3b7..88d589d159 100644 --- a/parse-options.h +++ b/parse-options.h @@ -85,6 +85,11 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, * token to explain the kind of argument this option wants. Does not * begin in capital letter, and does not end with a full stop. * Should be wrapped by N_() for translation. + * Is automatically enclosed in brackets when printed, unless it + * contains any of the following characters: ()<>[]| + * E.g. "name" is shown as "<name>" to indicate that a name value + * needs to be supplied, not the literal string "name", but + * "<start>,<end>" and "(this|that)" are printed verbatim. * * `help`:: * the short help associated to what the option does. -- 2.34.1
René Scharfe <l.s.r@web.de> writes: > Now that I read the whole comment, I think the right place to introduce > the automatic brackets is the description of argh some lines up. > > --- >8 --- > Subject: [PATCH 5/5] parse-options: document bracketing of argh > > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > parse-options.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/parse-options.h b/parse-options.h > index e22846d3b7..88d589d159 100644 > --- a/parse-options.h > +++ b/parse-options.h > @@ -85,6 +85,11 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, > * token to explain the kind of argument this option wants. Does not > * begin in capital letter, and does not end with a full stop. > * Should be wrapped by N_() for translation. > + * Is automatically enclosed in brackets when printed, unless it > + * contains any of the following characters: ()<>[]| > + * E.g. "name" is shown as "<name>" to indicate that a name value > + * needs to be supplied, not the literal string "name", but > + * "<start>,<end>" and "(this|that)" are printed verbatim. > * > * `help`:: > * the short help associated to what the option does. Very nice. This version gives the necessary information in (almost) one place. I said (almost) because "it contains any of ..." is not the only way to decline the <automatic angle brackets>, and am wondering if it is more helpful to say something like ... when printed, unless PARSE_OPT_LITERAL_ARGHELP is set in the flags, or it contains any of the following characters: ... and then shrink the description of the flag bit to PARSE_OPT_LITERAL_ARGHELP: controls if `argh` is enclosed in in brackets when shown (see the description on `argh` above).
Am 20.01.22 um 19:25 schrieb Junio C Hamano: > René Scharfe <l.s.r@web.de> writes: > >> Now that I read the whole comment, I think the right place to introduce >> the automatic brackets is the description of argh some lines up. >> >> --- >8 --- >> Subject: [PATCH 5/5] parse-options: document bracketing of argh >> >> Signed-off-by: René Scharfe <l.s.r@web.de> >> --- >> parse-options.h | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/parse-options.h b/parse-options.h >> index e22846d3b7..88d589d159 100644 >> --- a/parse-options.h >> +++ b/parse-options.h >> @@ -85,6 +85,11 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, >> * token to explain the kind of argument this option wants. Does not >> * begin in capital letter, and does not end with a full stop. >> * Should be wrapped by N_() for translation. >> + * Is automatically enclosed in brackets when printed, unless it >> + * contains any of the following characters: ()<>[]| >> + * E.g. "name" is shown as "<name>" to indicate that a name value >> + * needs to be supplied, not the literal string "name", but >> + * "<start>,<end>" and "(this|that)" are printed verbatim. >> * >> * `help`:: >> * the short help associated to what the option does. > > Very nice. > > This version gives the necessary information in (almost) one place. > > I said (almost) because "it contains any of ..." is not the only way > to decline the <automatic angle brackets>, and am wondering if it is > more helpful to say something like > > ... when printed, unless PARSE_OPT_LITERAL_ARGHELP is set in > the flags, or it contains any of the following characters: ... > > and then shrink the description of the flag bit to > > PARSE_OPT_LITERAL_ARGHELP: controls if `argh` is enclosed in in > brackets when shown (see the description on `argh` above). > The idea was to document the base behavior at the top and the effects of flags at the bottom. Blurring this distinction and cross-referencing gives a better whole, though, I agree. It would have helped me find the right place to put the list of special chars, for one thing. So how about this? --- >8 --- Subject: [PATCH v2] parse-options: document bracketing of argh Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: René Scharfe <l.s.r@web.de> --- parse-options.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/parse-options.h b/parse-options.h index e22846d3b7..2e801b3c9a 100644 --- a/parse-options.h +++ b/parse-options.h @@ -85,6 +85,11 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, * token to explain the kind of argument this option wants. Does not * begin in capital letter, and does not end with a full stop. * Should be wrapped by N_() for translation. + * Is enclosed in brackets when printed, unless PARSE_OPT_LITERAL_ARGHELP + * is set in `flags` or it contains any of the following characters: ()<>[]| + * E.g. "name" is shown as "<name>" to indicate that a name value + * needs to be supplied, not the literal string "name", but + * "<start>,<end>" and "(this|that)" are printed verbatim. * * `help`:: * the short help associated to what the option does. @@ -105,9 +110,8 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, * not last it will require an argument. * Should not be used with PARSE_OPT_OPTARG. * PARSE_OPT_NODASH: this option doesn't start with a dash. - * PARSE_OPT_LITERAL_ARGHELP: says that argh shouldn't be enclosed in brackets - * (i.e. '<argh>') in the help message. - * Useful for options with multiple parameters. + * PARSE_OPT_LITERAL_ARGHELP: says that `argh` shouldn't be enclosed in + * brackets (see `argh` description above). * PARSE_OPT_NOCOMPLETE: by default all visible options are completable * by git-completion.bash. This option suppresses that. * PARSE_OPT_COMP_ARG: this option forces to git-completion.bash to -- 2.34.1
René Scharfe <l.s.r@web.de> writes: > The idea was to document the base behavior at the top and the effects of > flags at the bottom. Blurring this distinction and cross-referencing > gives a better whole, though, I agree. It would have helped me find the > right place to put the list of special chars, for one thing. So how > about this? > > --- >8 --- > Subject: [PATCH v2] parse-options: document bracketing of argh > > Helped-by: Junio C Hamano <gitster@pobox.com> > Signed-off-by: René Scharfe <l.s.r@web.de> > --- > parse-options.h | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/parse-options.h b/parse-options.h > index e22846d3b7..2e801b3c9a 100644 > --- a/parse-options.h > +++ b/parse-options.h > @@ -85,6 +85,11 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, > * token to explain the kind of argument this option wants. Does not > * begin in capital letter, and does not end with a full stop. > * Should be wrapped by N_() for translation. > + * Is enclosed in brackets when printed, unless PARSE_OPT_LITERAL_ARGHELP > + * is set in `flags` or it contains any of the following characters: ()<>[]| > + * E.g. "name" is shown as "<name>" to indicate that a name value > + * needs to be supplied, not the literal string "name", but > + * "<start>,<end>" and "(this|that)" are printed verbatim. Since "does not begin", "does not end", "should be wrapped" are about how it appears in the initializer of the struct option, I had to read twice before realizing that "Is enclosed" is *not* about what the developer has to do. Making it clear that this is not part of "enumeration of sentences, which omit the same subject, that describe how the value appears in the source", e.g. When "git cmd -h" shows it, `argh` is enclosed in <brackets>, unless ... would have avoided the confusion. Other than that, I think this version is the clearest and easiest to understand among the options in this thread we have seen so far. Thanks. > * > * `help`:: > * the short help associated to what the option does. > @@ -105,9 +110,8 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, > * not last it will require an argument. > * Should not be used with PARSE_OPT_OPTARG. > * PARSE_OPT_NODASH: this option doesn't start with a dash. > - * PARSE_OPT_LITERAL_ARGHELP: says that argh shouldn't be enclosed in brackets > - * (i.e. '<argh>') in the help message. > - * Useful for options with multiple parameters. > + * PARSE_OPT_LITERAL_ARGHELP: says that `argh` shouldn't be enclosed in > + * brackets (see `argh` description above). > * PARSE_OPT_NOCOMPLETE: by default all visible options are completable > * by git-completion.bash. This option suppresses that. > * PARSE_OPT_COMP_ARG: this option forces to git-completion.bash to > -- > 2.34.1
diff --git a/builtin/am.c b/builtin/am.c index b6be1f1cb1..fa8d28794a 100644 --- a/builtin/am.c +++ b/builtin/am.c @@ -2402,7 +2402,7 @@ int cmd_am(int argc, const char **argv, const char *prefix) { OPTION_CALLBACK, 0, "show-current-patch", &resume.mode, "(diff|raw)", N_("show the patch being applied"), - PARSE_OPT_CMDMODE | PARSE_OPT_OPTARG | PARSE_OPT_NONEG | PARSE_OPT_LITERAL_ARGHELP, + PARSE_OPT_CMDMODE | PARSE_OPT_OPTARG | PARSE_OPT_NONEG, parse_opt_show_current_patch, RESUME_SHOW_PATCH }, OPT_CMDMODE(0, "allow-empty", &resume.mode, N_("record the empty patch as an empty commit"), diff --git a/builtin/push.c b/builtin/push.c index 359db90321..4fa6dfbd09 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -552,7 +552,7 @@ int cmd_push(int argc, const char **argv, const char *prefix) OPT_BIT('f', "force", &flags, N_("force updates"), TRANSPORT_PUSH_FORCE), OPT_CALLBACK_F(0, CAS_OPT_NAME, &cas, N_("<refname>:<expect>"), N_("require old value of ref to be at this value"), - PARSE_OPT_OPTARG | PARSE_OPT_LITERAL_ARGHELP, parseopt_push_cas_option), + PARSE_OPT_OPTARG, parseopt_push_cas_option), OPT_BIT(0, TRANS_OPT_FORCE_IF_INCLUDES, &flags, N_("require remote updates to be integrated locally"), TRANSPORT_PUSH_FORCE_IF_INCLUDES), diff --git a/parse-options.h b/parse-options.h index e22846d3b7..8d089fb3ae 100644 --- a/parse-options.h +++ b/parse-options.h @@ -108,6 +108,8 @@ typedef enum parse_opt_result parse_opt_ll_cb(struct parse_opt_ctx_t *ctx, * PARSE_OPT_LITERAL_ARGHELP: says that argh shouldn't be enclosed in brackets * (i.e. '<argh>') in the help message. * Useful for options with multiple parameters. + * Automatically enabled if argh contains any + * of the following characters: ()<>[]| * PARSE_OPT_NOCOMPLETE: by default all visible options are completable * by git-completion.bash. This option suppresses that. * PARSE_OPT_COMP_ARG: this option forces to git-completion.bash to
The help strings for arguments are enclosed in angle brackets automatically. E.g. if argh is specified as "name", "--option <name>" is printed, to indicate that users need to supply an actual name. The flag PARSE_OPT_LITERAL_ARGHELP turns this off, so that "--option name" is printed instead, to indicate that the literal string needs to be supplied -- a rare case. This flag is enabled automatically if argh contains special characters like brackets. The developer is supposed to provide any required angle brackets for more complicated cases. E.g. if argh is "<start>,<end>" then "--option <start>,<end>" is printed. Add a comment to mention this PARSE_OPT_LITERAL_ARGHELP behavior. Also remove the flag from option definitions for which it's inferred automatically. Signed-off-by: René Scharfe <l.s.r@web.de> --- Somehow I feel this is not enough, but I can't pin down what's missing. builtin/am.c | 2 +- builtin/push.c | 2 +- parse-options.h | 2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) -- 2.34.1