Hi Junio,
Thanks for the review!
On 9/12/19 1:17 PM, Junio C Hamano wrote:
>> +'git multi-pack-index' [--object-dir=<dir>] <subcommand> [--[no-]progress]
>
> I am wondering what the reasoning behind having this new one *after*
> the subcommand while the existing one *before* is. Isn't the
> --[no-]progress option supported by all subcommands of the
> multi-pack-index command, just like the --object-dir=<dir> option
> is?
>
> always show "global --options, subcommand, and then subcommand --options" order).
Thanks for calling this out. I didn't have a specific reason for making this
option appear after the subcommand. I tried looking at other commands as
examples and I missed that there's a specific ordering based on the type
of the option. I will clean this up in the next patch.
> I also see in the code that
> handles opts.batch_size that there is a workaround for this inverted
> code structure to make sure subcommands other than repack does not
> allow --batch-size option specified.
> we probably would want to correct the use
> of parse_options() API in the implementation of this command before
> adding any new option or subcommand.
To confirm I understand, is the recommendation that
cmd_multi_pack_index be updated to only parse "batch-size" for the repack
subcommand (i.e. use PARSE_OPT_STOP_AT_NON_OPTION to parse all of the common
options, and then only parse "batch-size" when the repack subcommand is running)?
>> @@ -47,14 +54,15 @@ int cmd_multi_pack_index(int argc, const char **argv,
>> trace2_cmd_mode(argv[0]);
>>
>> if (!strcmp(argv[0], "repack"))
>> - return midx_repack(the_repository, opts.object_dir, (size_t)opts.batch_size);
>> + return midx_repack(the_repository, opts.object_dir,
>> + (size_t)opts.batch_size, flags);
>> if (opts.batch_size)
>> die(_("--batch-size option is only for 'repack' subcommand"));
>>
>> if (!strcmp(argv[0], "write"))
>> return write_midx_file(opts.object_dir);
>> if (!strcmp(argv[0], "verify"))
>> - return verify_midx_file(the_repository, opts.object_dir);
>> + return verify_midx_file(the_repository, opts.object_dir, flags);
>> if (!strcmp(argv[0], "expire"))
>> return expire_midx_packs(the_repository, opts.object_dir);
>
> We can see that the new option only affects "verify", even though
> the SYNOPSIS and usage text pretends that everybody understands and
> reacts to it. Shouldn't it be documented just like how --batch-size
> is documented that it is understood only by "repack"?
>
> If the mid-term aspiration of this patch is to later enhance other
> subcommands to also understand the progress output or verbosity
> option (and if the excuse given as a response to the above analysis
> is "this is just a first step, more will come later")
Yep this was my thinking. Today "repack" and "verify" are the only subcommands
that have any progress output but as the other subcommands learn how to provide
progress the [--[no-]progress] option can be used to control it.
> instead of adding a "unsigned flag" local variable to the function, it would
> probably make much more sense to
>
> (1) make struct opts_multi_pack_index as a part of the public API
> between cmd_multi_pack_index() and midx.c and document it in
> midx.h;
>
> (2) instead of passing opts.object_dir to existing command
> implementations, pass &opts, the pointer to the whole
> structure;
>
> (3) add a new field "unsigned progress" to the structure, and teach
> the command line parser to flip it upon seeing "--[no-]progress".
>
Thanks for this suggestion I'll use this approach in the next patch.
One small point to clarify, in the current struct I'm using an int for
"progress" because OPT_BOOL expects an int*. Do you have any concerns with
keeping "progress" as an int in the public struct, or would you rather
cmd_multi_pack_index parse an int internally and use it to populate the
public struct?
Thanks!
William
