Re: [PATCH 6/6] diff-merges: let -m imply -p

From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: "Elijah Newren" <newren@gmail.com>, "Jeff King" <peff@peff.net>,
	"Philip Oakley" <philipoakley@iee.email>,
	"Felipe Contreras" <felipe.contreras@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Alex Henrie" <alexhenrie24@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>
Subject: Re: [PATCH 6/6] diff-merges: let -m imply -p
Date: Wed, 12 May 2021 08:40:57 +0900	[thread overview]
Message-ID: <xmqqcztwj0ty.fsf@gitster.g> (raw)
In-Reply-To: <87h7j9ne7j.fsf@osv.gnss.ru> (Sergey Organov's message of "Wed, 12 May 2021 00:38:24 +0300")

Sergey Organov <sorganov@gmail.com> writes:

>> But I do think that it is an utterly misleading option to show
>> merges in general.  When "log" is used with the "--first-parent"
>> traversal, "compare with the first parent to show everything the
>> side branch did" is an acceptable alternative, but even there, it is
>> far less suitable than the "remerge" or "cc", I would think, as the
>> default format.
>
> What I still fail to see is why somebody wants to mix traversal rules
> with representation of merge commits, sorry.

It is not about "mixing".

What I meant was that diff between the pre-merge state and the merge
result as two-tree comparison may be an acceptable view of "what did
this _merge_ contribute to the history" and that is in line is what
the first-parent traversal is trying to show the reader of the
history, which is "this merge contributed to the history, and then
this other merge contributed to the history, ...".  It also may make
sense when one is inspecting a merge in isolation, i.e. "git show M".

When one is viewing individual commits without omitting commits on
the side branch, however, showing "what did the side branch as a
whole contributed to the history at this merge" makes little sense
and is misleading.  Such a patch given for a merge mostly overlaps
with what the reader sees immediately after seeing the merge
(i.e. the commits on the side branch, with their own patches, each
of which has already been shown in the first-parent comparison of
the merge).  In other words, "git log --no-first-parent" is about
contribution of each single commit (whether it is a merge or a
non-merge) makes, and the --diff-merges=1 presentation is not in
line with that worldview, in which the contribution to the history
the merge alone makes is what --cc or remerge tries to show,
i.e. "what did the merge do, on top of what the commits on the side
branch contributed to the history?"

So, it is not like two unrelated things are mixed together.  It is
more like showing the result of a merge as a diff relative to its
first-parent is tied to and consistent with the viewpoint of history
as single strand of pearls that is a series of merges into the
first-parent chain, but not with non-first-parent presentation of
the history.