Re: [PATCH 2/2] merge-recursive: i18n submodule merge output and respect verbosity

[Elijah Newren <newren@gmail.com>]

I know I said the patches looked okay earlier, but I just noticed something...

On Thu, May 10, 2018 at 2:19 PM, Stefan Beller <sbeller@google.com> wrote:

>         case 1:
> -               MERGE_WARNING(path, "not fast-forward");
> -               fprintf(stderr, "Found a possible merge resolution "
> -                               "for the submodule:\n");
> +               output(o, 1, _("Failed to merge submodule %s (not fast-forward)"), path);

We allow folks to set GIT_MERGE_VERBOSITY to change how much output
they get.  A setting of 1 should only show conflicts or major
warnings.  2 is the default and adds a few more messages (e.g.
"Auto-merging $PATH", "Adding $PATH" for one-sided adds, etc.), higher
levels show even more.

Anyway this output message is correct to use level 1 since this is a
conflict, but...

> +               output(o, 1, _("Found a possible merge resolution for the submodule:\n"));

I think this should use level 2.

>                 print_commit((struct commit *) merges.objects[0].item);
> -               fprintf(stderr,
> +               output(o, 1, _(
>                        "If this is correct simply add it to the index "
>                        "for example\n"
>                        "by using:\n\n"
>                        "  git update-index --cacheinfo 160000 %s \"%s\"\n\n"
>-                       "which will accept this suggestion.\n",
>+                       "which will accept this suggestion.\n"),
>                        oid_to_hex(&merges.objects[0].item->oid), path);

and so should this one (in fact, I'm tempted to say these last two
should use level 3, but since it looks like a command users may have
difficulty finding on their own, I'm okay with going with 2).