| Message ID | 20230831071230.GA3197647@coredump.intra.peff.net (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | more unused parameters in parseopt callbacks | expand |
On Thu, Aug 31, 2023 at 03:12:30AM -0400, Jeff King wrote: > The "xopts" variable uses a custom array with ALLOC_GROW(). Using a > strvec simplifies things a bit. We need fewer variables, and we can also > ditch our custom parseopt callback in favor of OPT_STRVEC(). > > As a bonus, this means that "--no-strategy-option", which was previously > a silent noop, now does something useful: like other list-like options, > it will clear the list of -X options seen so far. > > Signed-off-by: Jeff King <peff@peff.net> > --- > I guess you could argue this is a backwards-incompatible change, but the > existing behavior of --no-strategy-option is so dumb that I can't > believe somebody would prefer it (plus revert/cherry-pick already use > OPT_STRVEC for their matching "-X"). > > I didn't bother adding a test since we're just re-using OPT_STRVEC code > that is used elsewhere. I only noticed the "revert/cherry-pick" thing while sending this patch out. But it seems that it was changed recently-ish, and Phillip noted the same behavior change there (along with mentioning merge.c). So now I doubly feel this is the right thing to do. :) -Peff
Hi Peff On 31/08/2023 08:22, Jeff King wrote: > On Thu, Aug 31, 2023 at 03:12:30AM -0400, Jeff King wrote: > I only noticed the "revert/cherry-pick" thing while sending this patch > out. But it seems that it was changed recently-ish, and Phillip noted > the same behavior change there (along with mentioning merge.c). So now I > doubly feel this is the right thing to do. :) Thanks for doing this, I had intended to follow up the cherry-pick/revert changes by changing merge as well but didn't get around to it. I think the current behavior is unlikely to be useful to anyone. Best Wishes Phillip
Jeff King <peff@peff.net> writes: > The "xopts" variable uses a custom array with ALLOC_GROW(). Using a > strvec simplifies things a bit. We need fewer variables, and we can also > ditch our custom parseopt callback in favor of OPT_STRVEC(). > > As a bonus, this means that "--no-strategy-option", which was previously > a silent noop, now does something useful: like other list-like options, > it will clear the list of -X options seen so far. > > Signed-off-by: Jeff King <peff@peff.net> > --- > I guess you could argue this is a backwards-incompatible change, but the > existing behavior of --no-strategy-option is so dumb that I can't > believe somebody would prefer it (plus revert/cherry-pick already use > OPT_STRVEC for their matching "-X"). > > I didn't bother adding a test since we're just re-using OPT_STRVEC code > that is used elsewhere. I do not think of any useful way to have "--no-strategy-option" on the command line (either as an early part of an alias or in a script) that does nothing (it's not like the command requires at least one -X option on the command line), either. Just like fb60b9f3 (sequencer: use struct strvec to store merge strategy options, 2023-04-10), which met no complaints about a possible fallout by the behaviour change, I do not think that this change even deserves an entry in the backward compatibility notes. We did not have strvec, let alone OPT_STRVEC(), back when the -Xopts was invented around the Git 1.7.0 cycle. The loss of custom xopts code is very nice. Thanks.
On Thu, Aug 31, 2023 at 08:46:25AM -0700, Junio C Hamano wrote: > > I guess you could argue this is a backwards-incompatible change, but the > > existing behavior of --no-strategy-option is so dumb that I can't > > believe somebody would prefer it (plus revert/cherry-pick already use > > OPT_STRVEC for their matching "-X"). > > > > I didn't bother adding a test since we're just re-using OPT_STRVEC code > > that is used elsewhere. > > I do not think of any useful way to have "--no-strategy-option" on > the command line (either as an early part of an alias or in a > script) that does nothing (it's not like the command requires at > least one -X option on the command line), either. Just like > fb60b9f3 (sequencer: use struct strvec to store merge strategy > options, 2023-04-10), which met no complaints about a possible > fallout by the behaviour change, I do not think that this change > even deserves an entry in the backward compatibility notes. I concur with both of you. In a project like this one, we should be rather generous with the set of things we expect users to do. But even in a quite generous interpretation, I cannot imagine anybody relying on this behavior, so I think skipping a mention of it in the backwards compatibility section makes sense. Thanks, Taylor
diff --git a/builtin/merge.c b/builtin/merge.c index de68910177..53e9fe70d9 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -79,8 +79,7 @@ static int overwrite_ignore = 1; static struct strbuf merge_msg = STRBUF_INIT; static struct strategy **use_strategies; static size_t use_strategies_nr, use_strategies_alloc; -static const char **xopts; -static size_t xopts_nr, xopts_alloc; +static struct strvec xopts = STRVEC_INIT; static const char *branch; static char *branch_mergeoptions; static int verbosity; @@ -242,17 +241,6 @@ static int option_parse_strategy(const struct option *opt, return 0; } -static int option_parse_x(const struct option *opt, - const char *arg, int unset) -{ - if (unset) - return 0; - - ALLOC_GROW(xopts, xopts_nr + 1, xopts_alloc); - xopts[xopts_nr++] = xstrdup(arg); - return 0; -} - static int option_parse_n(const struct option *opt, const char *arg, int unset) { @@ -287,8 +275,8 @@ static struct option builtin_merge_options[] = { N_("verify that the named commit has a valid GPG signature")), OPT_CALLBACK('s', "strategy", &use_strategies, N_("strategy"), N_("merge strategy to use"), option_parse_strategy), - OPT_CALLBACK('X', "strategy-option", &xopts, N_("option=value"), - N_("option for selected merge strategy"), option_parse_x), + OPT_STRVEC('X', "strategy-option", &xopts, N_("option=value"), + N_("option for selected merge strategy")), OPT_CALLBACK('m', "message", &merge_msg, N_("message"), N_("merge commit message (for a non-fast-forward merge)"), option_parse_message), @@ -749,9 +737,9 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common, o.show_rename_progress = show_progress == -1 ? isatty(2) : show_progress; - for (x = 0; x < xopts_nr; x++) - if (parse_merge_opt(&o, xopts[x])) - die(_("unknown strategy option: -X%s"), xopts[x]); + for (x = 0; x < xopts.nr; x++) + if (parse_merge_opt(&o, xopts.v[x])) + die(_("unknown strategy option: -X%s"), xopts.v[x]); o.branch1 = head_arg; o.branch2 = merge_remote_util(remoteheads->item)->name; @@ -777,7 +765,7 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common, return clean ? 0 : 1; } else { return try_merge_command(the_repository, - strategy, xopts_nr, xopts, + strategy, xopts.nr, xopts.v, common, head_arg, remoteheads); } }
The "xopts" variable uses a custom array with ALLOC_GROW(). Using a strvec simplifies things a bit. We need fewer variables, and we can also ditch our custom parseopt callback in favor of OPT_STRVEC(). As a bonus, this means that "--no-strategy-option", which was previously a silent noop, now does something useful: like other list-like options, it will clear the list of -X options seen so far. Signed-off-by: Jeff King <peff@peff.net> --- I guess you could argue this is a backwards-incompatible change, but the existing behavior of --no-strategy-option is so dumb that I can't believe somebody would prefer it (plus revert/cherry-pick already use OPT_STRVEC for their matching "-X"). I didn't bother adding a test since we're just re-using OPT_STRVEC code that is used elsewhere. builtin/merge.c | 26 +++++++------------------- 1 file changed, 7 insertions(+), 19 deletions(-)