Thread (164 messages) flat view 164 messages, 7 authors, 2021-09-18

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)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help