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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 24, 2024, 17:34 UTC
Message-ID: <xmqqr0i6fxe2.fsf@gitster.g>
In-Reply-To: <CABPp-BE4zqRX=wd5EBj96hzCS8V73QpdN-2pCpv7qMdkpkX93w@mail.gmail.com>

Elijah Newren <newren@gmail.com> writes:

Show 5 quoted lines

> 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?

;-)