git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Leif Middelschulte <leif.middelschulte@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 1/1] Inform about fast-forwarding of submodules during merge
Date: Tue, 15 May 2018 16:34:27 +0900
Message-ID: <xmqqzi118j98.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <CABPp-BGp_zP8Z2S8FskiNvhNeQH3f=HdnQ39vX6xQz=oSyVfMQ@mail.gmail.com> (Elijah Newren's message of "Mon, 14 May 2018 18:17:09 -0700")

Elijah Newren <newren@gmail.com> writes:

> Hi Leif,
>
> On Mon, May 14, 2018 at 1:57 PM, Leif Middelschulte
> <leif.middelschulte@gmail.com> 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.

  reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-10 18:26 [PATCH 0/1] warn about auto fast-forwarded submodules during merges Leif Middelschulte
2018-05-10 18:26 ` [PATCH 1/1] Warn about fast-forwarding of submodules during merge Leif Middelschulte
2018-05-10 18:49   ` Stefan Beller
2018-05-10 20:30     ` Leif Middelschulte
2018-05-10 21:19       ` [PATCH 0/2] Submodule merging: i18n, verbosity Stefan Beller
2018-05-10 21:19         ` [PATCH 1/2] submodule.c: move submodule merging to merge-recursive.c Stefan Beller
2018-05-10 21:19         ` [PATCH 2/2] merge-recursive: i18n submodule merge output and respect verbosity Stefan Beller
2018-05-15  1:25           ` Elijah Newren
2018-05-11  0:04         ` [PATCH 0/2] Submodule merging: i18n, verbosity Elijah Newren
2018-05-11  1:00           ` Stefan Beller
2018-05-14 20:57             ` [PATCH 0/1] rebased: inform about auto submodule ff during merge Leif Middelschulte
2018-05-14 20:57               ` [PATCH 1/1] Inform about fast-forwarding of submodules " Leif Middelschulte
2018-05-15  0:41                 ` Stefan Beller
2018-05-15  1:17                 ` Elijah Newren
2018-05-15  7:34                   ` Junio C Hamano [this message]
2018-05-17 18:40 [PATCH] merge-recursive: give notice when submodule commit gets fast-forwarded Stefan Beller
2018-05-18 19:48 ` [PATCH v3 0/1] rebased: inform about auto submodule ff Leif Middelschulte
2018-05-18 19:48   ` [PATCH 1/1] Inform about fast-forwarding of submodules during merge Leif Middelschulte
2018-05-18 21:25     ` Elijah Newren
2018-05-21  4:12       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqzi118j98.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=leif.middelschulte@gmail.com \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git