Re: [PATCH 2/2] diff-merges: introduce '-d' option

From: Junio C Hamano <gitster@pobox.com>
To: Sergey Organov <sorganov@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/2] diff-merges: introduce '-d' option
Date: Fri, 15 Sep 2023 10:24:43 -0700	[thread overview]
Message-ID: <xmqqzg1nfixw.fsf@gitster.g> (raw)
In-Reply-To: <87y1h8wbpo.fsf@osv.gnss.ru> (Sergey Organov's message of "Fri, 15 Sep 2023 02:56:35 +0300")

Sergey Organov <sorganov@gmail.com> writes:

> I don't see why desire to look at diff-to-first-parent on "side"
> branches is any different from desire to look at them on "primary"
> branch

Yeah, but that is not what I meant.  The above argues for why
"--diff-merges=first-parent" should exist independently from the
"--first-parent" traversal *and* display option.  I am not saying
it should not exist.

But I view that the desire to look at any commits and its changes on
the "side" branch at all *is* at odds with the wish to look at
first-parent change for merge commits.  Once you decide to look at
first-parent change for a merge commit, then every change you see
for each commit on the "side" branch, whether it is shown as
first-parent diff or N pairwise diffs, is what you have already seen
in the change in the merge commit, because "git log" goes newer to
older, and the commits on the side branches appear after the merge
that brings them to the mainline.

Making "log -d" mean "log --diff-merges=first-parent --patch" lets
that less useful combination ("show first-parent patches but
traverse side branches as well") squat on the short and sweet "-d"
that could be used for more useful "log --first-parent --patch",
which would also be more common and intuitive to users, and that is
what I suspect will become problematic in the longer run.

Thanks.