On Mon, Feb 15, 2021 at 09:39:11PM +0100, Ævar Arnfjörð Bjarmason wrote: > > On Mon, Feb 15 2021, Taylor Blau wrote: > > > On Mon, Feb 15, 2021 at 07:41:16PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> Make use of the parse_options_concat() so we don't need to copy/paste > >> common options like --object-dir. This is inspired by a similar change > >> to "checkout" in 2087182272 > >> (checkout: split options[] array in three pieces, 2019-03-29). > >> > >> A minor behavior change here is that now we're going to list both > >> --object-dir and --progress first, before we'd list --progress along > >> with other options. The final version of this patch that was picked up is at https://public-inbox.org/git/patch-v4-3.7-32cc0d1c7bc-20210823T122854Z-avarab@xxxxxxxxx/ I reply to this old version because of the following pieces of the discussion: > > "Behavior change" referring only to the output of `git commit-graph -h`, > > no? > > > > Looking at the code (and understanding this whole situation a little bit > > better), I'd think that this wouldn't cause us to parse anything > > differently before or after this change, right? > > Indeed, I just mean the "-h" or "--invalid-opt" output changed in the > order we show the options in. [...] > but I wanted to just focus on > refactoring existing behavior & get rid of the copy/pasted options No, there is more behavior change: since 84e4484f12 (commit-graph: use parse_options_concat(), 2021-08-23) the 'git commit-graph' command does accept the '--[no-]progress' options as well, but before that only its subcommands did, and 'git commit-graph --progress ...' errored out with "unknown option". Worse, sometimes 'git commit-graph --progress ...' doesn't work as it's supposed to. The patch below descibes the problem and fixes it, but on second thought I don't think that it is the right approach. In general, even when all subcommands of a git command understand a particular --option, that does not mean that it's a good idea to teach that option to that git command. E.g. what if we later add another subcommand for which that --option doesn't make any sense? And from the quoted discussion above it seems that teaching 'git commit-graph' the '--progress' option was not intentional at all. 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. --- >8 --- Subject: [PATCH] commit-graph: fix 'git commit-graph --[no-]progress ...' Until recenly 'git commit-graph' didn't have a '--progress' option, only its subcommands did, but this changed with 84e4484f12 (commit-graph: use parse_options_concat(), 2021-08-23), and now the 'git commit-graph' command accepts the '--[no-]progress' options as well. Alas, they don't always works as they are supposed to, because the isatty(2) check is only performed in the subcommands, i.e. after the "main" 'git commit-graph' command has parsed its options, and it unconditionally overwrites whatever '--[no-]progress' option might have been given: $ GIT_PROGRESS_DELAY=0 git commit-graph --no-progress write --reachable Collecting referenced commits: 1617, done. Loading known commits in commit graph: 100% (1617/1617), done. [...] $ GIT_PROGRESS_DELAY=0 git commit-graph --progress write 2>out $ wc -c out 0 out Move the isatty(2) check to cmd_commit_graph(), before it calls parse_options(), so 'git commit-graph --[no-]progress' will be able to override it as well. Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx> --- builtin/commit-graph.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c index 21fc6e934b..3a873ceaf6 100644 --- a/builtin/commit-graph.c +++ b/builtin/commit-graph.c @@ -101,7 +101,6 @@ static int graph_verify(int argc, const char **argv) trace2_cmd_mode("verify"); - opts.progress = isatty(2); argc = parse_options(argc, argv, NULL, options, builtin_commit_graph_verify_usage, 0); @@ -250,7 +249,6 @@ static int graph_write(int argc, const char **argv) }; struct option *options = add_common_options(builtin_commit_graph_write_options); - opts.progress = isatty(2); opts.enable_changed_paths = -1; write_opts.size_multiple = 2; write_opts.max_commits = 0; @@ -331,6 +329,7 @@ int cmd_commit_graph(int argc, const char **argv, const char *prefix) struct option *builtin_commit_graph_options = common_opts; git_config(git_default_config, NULL); + opts.progress = isatty(2); argc = parse_options(argc, argv, prefix, builtin_commit_graph_options, builtin_commit_graph_usage, -- 2.33.0.517.ga8dcee0d0a --- 8< ---
