Elijah Newren <newren@xxxxxxxxx> writes:
> Hi Leif,
>
> On Mon, May 14, 2018 at 1:57 PM, Leif Middelschulte
> <leif.middelschulte@xxxxxxxxx> wrote:
>
> Thanks for updating the patch on top of Stefan's series. :-)
>
>> /* Case #1: a is contained in b or vice versa */
>> if (in_merge_bases(commit_a, commit_b)) {
>> oidcpy(result, b);
>> + output(o, 1, _("Note: Fast-forwarding submodule %s to the following commit"), path);
>> + output_commit_title(o, commit_b);
>
> Level 1 is for conflicts; I don't think this message should have
> higher priority than "Auto-merging $PATH" for normal files, so it
> needs to be 2 (or maybe 3, see below) rather than 1. (The default
> output level is 2, so it'd still be shown, but we do allow people to
> remove informational message and just get conflicts by setting
> GIT_MERGE_VERBOSITY to 1, or request extra information by setting it
> higher)
>
> Also, this two-line message seems somewhat verbose compared to the
> other messages in merge_submdoule(), and when compared to the simple
> "Auto-merging $PATH" we do for normal files. The multi-line nature of
> it particularly strikes me; the merge-recursive code has generally
> avoided multi-line messages even for conflicts.
>
> In comparison, your original patch just had ("Fast-forwarding
> submodule %s", path).
FWIW, I share both of your surprises. Between level 2 and 3, after
skimming merge-recursive.c for existing use of output levels, I
think the situation for non-submodule merges that is closest to
these two cases the patch covers for submodules is probably the
message given when content merge happened to end up with what we
already had. It is part of a normal merge operation that is not a
singificant event in the larger picture, yet it is rather rare and
interesting when you are curious on events that occur infrequently.
So a one-liner message as everybody else emitted at level 3 or more
verbose would probably be a good balance with the remainder of the
system, I would think.
Thanks for a review.
