Re: [PATCH 3/5] commit-graph: use parse_options_concat()

["SZEDER Gábor" <szeder.dev@gmail.com>]

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@gmail.com/

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@gmail.com>
---
 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<  ---