"William Baker via GitGitGadget" <gitgitgad...@gmail.com> writes:

> From: William Baker <william.ba...@microsoft.com>
>
> Signed-off-by: William Baker <william.ba...@microsoft.com>
> ---
>  builtin/multi-pack-index.c |  8 ++++----
>  builtin/repack.c           |  2 +-
>  midx.c                     |  8 ++++----
>  midx.h                     | 10 ++++++----
>  4 files changed, 15 insertions(+), 13 deletions(-)
>
> diff --git a/builtin/multi-pack-index.c b/builtin/multi-pack-index.c
> index b1ea1a6aa1..e86b8cd17d 100644
> --- a/builtin/multi-pack-index.c
> +++ b/builtin/multi-pack-index.c
> @@ -47,16 +47,16 @@ 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, 0);
>       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);
> +             return write_midx_file(opts.object_dir, 0);
>       if (!strcmp(argv[0], "verify"))
> -             return verify_midx_file(the_repository, opts.object_dir);
> +             return verify_midx_file(the_repository, opts.object_dir, 0);
>       if (!strcmp(argv[0], "expire"))
> -             return expire_midx_packs(the_repository, opts.object_dir);
> +             return expire_midx_packs(the_repository, opts.object_dir, 0);

Hmm, I actually would have expected to see a new .progress field in
the opts structure and these lower-level functions would start
taking a pointer to the whole opts structure, instead of just a
pointer to a single member opts.object_dir.  That way, we can later
extend and enrich the interface between this caller and the
underlying functions without much patch noise in the dispatch layer
(i.e. here).

This step is meant to be just preparing by extending the interface
and passing the new argument throughout the callchain, I believe,
and it looks correctly done, assuming that we are OK to take this
"add a separate 'progress' parameter, when we need more parameters
later, the interface will gain more and more parameters" approach.

Reply via email to