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

[Junio C Hamano <gitster@pobox.com>]

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

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