Re: [PATCH v3 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert

From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Michael Lohmann <mi.al.lohmann@gmail.com>,
	 git@vger.kernel.org, phillip.wood123@gmail.com,
	 Johannes Sixt <j6t@kdbg.org>
Subject: Re: [PATCH v3 2/2] revision: Implement `git log --merge` also for rebase/cherry_pick/revert
Date: Wed, 24 Jan 2024 09:34:45 -0800	[thread overview]
Message-ID: <xmqqr0i6fxe2.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BE4zqRX=wd5EBj96hzCS8V73QpdN-2pCpv7qMdkpkX93w@mail.gmail.com> (Elijah Newren's message of "Tue, 23 Jan 2024 23:06:08 -0800")

Elijah Newren <newren@gmail.com> writes:

> I had to go look up previous versions to see the discussion of why
> this was useful for things other than merge.  I agree with Phillip
> from https://lore.kernel.org/git/648774b5-5208-42d3-95c7-e0cba4d6a159@gmail.com/,
> that the commit message _needs_ to explain this, likely using some of
> Junio's explanation.

Please note that I am not very happy with that "explanation" myself.
The only thing I can still agree to in that message myself is that
it is sensible for "log --merge" to go down all the way to the root
of the histories leading to MERGE_HEAD and HEAD in the "merging two
unrelated histories" scenario.  Treating CHERRY_PICK_HEAD and others
the same way, to me, almost sounds as if we are saying "all the
commits behind the commits involved in the conflicted operation are
worth looking at", which is not a very useful or productive thing.

> Also, what about cases where users do a cherry-pick in the middle of a
> rebase, so that both REBASE_HEAD and CHERRY_PICK_HEAD exist?  What
> then?

;-)