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

[Michael Lohmann <mi.al.lohmann@gmail.com>]

> > tells us. Indeed there HEAD and CHERRY_PICK_HEAD may not share a
> > common ancestor. As I say I've not used "git log --merge" so maybe I'm
> > missing the reason why it would be useful when cherry-picking or
> > rebasing.
> 
> Good question.  It is the whole point of cherry-pick that
> CHERRY_PICK_HEAD and the current HEAD may not have any meaningful
> ancestry relationship, so yes, it is questionable to use the same
> logic for "log --merge" between HEAD...CHERRY_PICK_HEAD, while using
> HEAD...MERGE_HEAD does make perfect sense.

I tried to say it in [1]: a merge also does not need a common ancestor! Try it:

   git init test
   cd test
   echo something > README.md
   git add --all
   git commit -m "initial commit"
   git remote add origin_git git://git.kernel.org/pub/scm/git/git.git
   git fetch origin_git master     # obviously no common ancestor
   git merge --allow-unrelated-histories origin_git/master
   # merge conflict
   git log --merge    # Still loggs all the conflicting commits

So indeed the command that Phillip wrote is not equivalent and the existing
logic already can deal with unrelated histories. Or am I misunderstanding?

Michael

[1] https://lore.kernel.org/git/20240112150346.73735-1-mi.al.lohmann@gmail.com/