Re: [PATCH 2/2] merge-recursive: i18n submodule merge output and respect verbosity
- Date: Mon, 14 May 2018 18:25:33 -0700
- From: Elijah Newren <newren@xxxxxxxxx>
- Subject: Re: [PATCH 2/2] merge-recursive: i18n submodule merge output and respect verbosity
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@xxxxxxxxxx> 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
> + 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.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.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).