Patrick Steinhardt <ps@xxxxxx> writes:
> Considering that both multi-remote and submodule fetches are user-facing
> features, using them in conjunction with `--porcelain` that is intended
> for scripting purposes is likely not going to be useful in the majority
> of cases. With that in mind these restrictions feel acceptable. If
> usecases for either of these come up in the future though it is easy
> enough to add a new "porcelain-v2" format that adds this information.
Two steps ago, the proposed log message still mentioned "--output-format",
which may want to be proofread again and revised.
> @@ -1786,7 +1810,8 @@ static int add_remote_or_group(const char *name, struct string_list *list)
> return 1;
> }
>
> -static void add_options_to_argv(struct strvec *argv)
> +static void add_options_to_argv(struct strvec *argv,
> + enum display_format format)
> {
> if (dry_run)
> strvec_push(argv, "--dry-run");
> @@ -1822,6 +1847,8 @@ static void add_options_to_argv(struct strvec *argv)
> strvec_push(argv, "--ipv6");
> if (!write_fetch_head)
> strvec_push(argv, "--no-write-fetch-head");
> + if (format == DISPLAY_FORMAT_PORCELAIN)
> + strvec_pushf(argv, "--porcelain");
> }
Hmph.
[PATCH 9/8] may want to also introduce and pass down the
"--output-format=full/compact" option, but that is clearly outside
of the scope of this step.
> +static int opt_parse_porcelain(const struct option *opt, const char *arg, int unset)
> +{
> + enum display_format *format = opt->value;
> + *format = DISPLAY_FORMAT_PORCELAIN;
> + return 0;
> +}
Lack of "if (unset) ..." worries me. Shouldn't the code allow
git fetch --porcelain --no-porcelain
to defeat an earlier one and revert back to the default?
Other than that the changes in this step were mostly expected and I
didn't spot anything glaringly wrong, but I didn't spend as much
time as I did for the other steps.
Thanks.
