Re: [RFC PATCH] `log --merge` also for rebase/cherry pick/revert

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 12, 2024, 21:14 UTC
Message-ID: <xmqqil3y9rvm.fsf@gitster.g>
In-Reply-To: <20240112150346.73735-1-mi.al.lohmann@gmail.com>

Michael Lohmann <mi.al.lohmann@gmail.com> writes:

Show 6 quoted lines

> Almost, but not quite: "git log —merge" only shows the commits touching the
> conflict, so it would be equivalent to (I think):
>
>    git log HEAD CHERRY_PICK_HEAD ^$(git merge-base HEAD CHERRY_PICK_HEAD) -- $(git diff --name-only --diff-filter=U --relative)
>
> (or replace CHERRY_PICK with one of the other actions)

It can certainly _reduce_ the noise, but I am not sure if it works over the right history segment. Let me think aloud a bit.

Let's imagine that in a history forked long time ago,

 O----O----O----O----X HEAD
  \
   Z---Z---Z---Z---A---B CHERRY_PICK_HEAD

where all commits modified the same path in question that you saw conflicts in when your "git cherry-pick B" stopped.

I do not know what to think about the changes to that path by the commits denoted by 'O', but the changes done to the path by commits denoted by 'Z' should have absolutely no relevance, as the whole point of cherry-picking B relative to A is because we do not care about what Zs did, no? For that matter, given that how we structure the 3-way merge for such a cherry-pick to "move from X the same way as you would move from A to B", how you got to X (i.e. Os) should not matter, either.

On the other hand, such a conflict may arise from the fact that Os and Zs made changes differently to cause the contents of the path at X and A differ significantly. So, OK, I can buy your argument that what Os and Zs to the conflicted path did can be interesting when understanding the conflict during such a cherry-pick.

>> Indeed there HEAD and CHERRY_PICK_HEAD may not share a common ancestor.
>
> True - but same for MERGE_HEAD ("git merge --allow-unrelated-histories"). I

But that is very different, isn't it? Merging two unrelated histories is like merging two histories where the common ancestor had an empty tree, i.e.

      o---o---o---X HEAD
     /
   (v) an imaginary ancestor with an empty tree
     \
      o---o---o---O MERGE_HEAD

so it is a reasonable degenerated behaviour to consider what all commits on both sides did to the paths in question.