phillip.wood123@xxxxxxxxx writes: > I should start by saying that I didn't know "git log --merge" existed > before I saw this message so please correct me if I've misunderstood > what this patch is doing. If I understand correctly it shows the > commits from each side of the merge and is equivalent to > > git log HEAD MERGE_HEAD ^$(git merge-base HEAD MERGE_HEAD) > > When a commit is cherry-picked the merge base used is > CHERRY_PICK_HEAD^ [*] so I'm not sure what > > git log HEAD CHERRY_PICK_HEAD ^$(git merge-base HEAD CHERRY_PICK_HEAD) > > 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.
