Re: [PATCH 3/5] commit-graph: use parse_options_concat()
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-09-18 07:27:21
On Sat, Sep 18 2021, Taylor Blau wrote:
On Fri, Sep 17, 2021 at 06:03:58PM -0400, Jeff King wrote:quoted
quoted
I'm inclined to think that '--progress' should rather be removed from the common 'git commit-graph' options; luckily it's not too late, because it hasn't been released yet.I wasn't following this series closely, but having seen your fix below, I'm inclined to agree with you. Just because we _can_ allow options before or after sub-commands does not necessarily make it a good idea.I agree. Suppose we had a "git commit-graph remove" sub-command that removed the commit-graph file (ignoring that there are probably better hypothetical examples than this ;)). It's not obvious what --progress means in the context of that mode.
Well, you might have as many as tens of commit-graph files, and could be running this on AIX where I/O is apparently implemented in terms of carrier pigeon messaging judging by how slow it is :) But as argued in https://lore.kernel.org/git/87zgsad6mn.fsf@evledraar.gmail.com/ (local) I don't see how it's going to be any more confusing to user than "git -c foo=bar version" (the -c does nothing there)>
Here's a patch that does what you and Gábor are suggesting as an alternative. Unfortunately, we can't do the same for the multi-pack-index command, since the analogous change there is 60ca94769c (builtin/multi-pack-index.c: split sub-commands, 2021-03-30), which was released in 2.32.
If we came up with some call about what we want subcommands in general to look like I'd think it would be fine to convert multi-pack-index to it, perhaps with some deprecation period where it would issue a warning() while it understood both forms.
quoted hunk ↗ jump to hunk
Anyway, as promised:--- 8< ---Subject: [PATCH] builtin/commit-graph.c: don't accept common --[no-]progress In 84e4484f12 (commit-graph: use parse_options_concat(), 2021-08-23) we unified common options of commit-graph's subcommands into a single "common_opts" array. But 84e4484f12 introduced a behavior change which is to accept the "--[no-]progress" option before any sub-commands, e.g., git commit-graph --progress write ... Prior to that commit, the above would error out with "unknown option". There are two issues with this behavior change. First is that the top-level --[no-]progress is not always respected. This is because isatty(2) is performed in the sub-commands, which unconditionally overwrites any --[no-]progress that was given at the top-level. But the second issue is that the existing sub-commands of commit-graph only happen to both have a sensible interpretation of what `--progress` or `--no-progress` means. If we ever added a sub-command which didn't have a notion of progress, we would be forced to ignore the top-level `--[no-]progress` altogether. Since we haven't released a version of Git that supports --[no-]progress as a top-level option for `git commit-graph`, let's remove it. Suggested-by: SZEDER Gábor <redacted> Signed-off-by: Taylor Blau <redacted> --- builtin/commit-graph.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c index 21fc6e934b..067587a0fd 100644 --- a/builtin/commit-graph.c +++ b/builtin/commit-graph.c@@ -50,8 +50,6 @@ static struct option common_opts[] = { OPT_STRING(0, "object-dir", &opts.obj_dir, N_("dir"), N_("the object directory to store the graph")), - OPT_BOOL(0, "progress", &opts.progress, - N_("force progress reporting")), OPT_END() };@@ -95,6 +93,8 @@ static int graph_verify(int argc, const char **argv) static struct option builtin_commit_graph_verify_options[] = { OPT_BOOL(0, "shallow", &opts.shallow, N_("if the commit-graph is split, only verify the tip file")), + OPT_BOOL(0, "progress", &opts.progress, + N_("force progress reporting")), OPT_END(), }; struct option *options = add_common_options(builtin_commit_graph_verify_options);@@ -246,6 +246,8 @@ static int graph_write(int argc, const char **argv) OPT_CALLBACK_F(0, "max-new-filters", &write_opts.max_new_filters, NULL, N_("maximum number of changed-path Bloom filters to compute"), 0, write_option_max_new_filters), + OPT_BOOL(0, "progress", &opts.progress, + N_("force progress reporting")), OPT_END(), }; struct option *options = add_common_options(builtin_commit_graph_write_options);
This is a good change, but if you're up for bonus points leaves the docs in an odd where we (as noted in [1]) document the --object-dir and --progress options under OPTIONS, but now only take the former before the sub-command. 1. https://lore.kernel.org/git/87zgsad6mn.fsf@evledraar.gmail.com/ (local)