> > 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@xxxxxxxxx/
