Hi Michael
On 12/01/2024 15:03, Michael Lohmann wrote:
Hi Phillip,
On 12. Jan 2024, at 12:01, phillip.wood123@xxxxxxxxx wrote:
I should start by saying that I didn't know "git log --merge" existed before
I saw this message
I also just found it and it looked very useful...
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)
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)
Thanks for clarifying that.
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
have to confess I did not check how it would behave under those circumstances.
It could either error, or (more helpful) show the log touching the file until
the root commit.
What I was trying to get at was that with "git merge" "git log --merge"
will show commits that are part of the merge. With "git cherry-pick"
that's not the case because we're selecting the commits to show using
the merge base of HEAD and CHERRY_PICK_HEAD while cherry-pick uses
CHERRY_PICK_HEAD^ as the base of the merge. I think Junio explains why
it is still useful to show those commits in [1] i.e. they help the user
understand the conflicts even though they are not part of the merge. It
might be worth expanding the commit message to explain that.
Best Wishes
Phillip
[1] https://lore.kernel.org/git/xmqqil3y9rvm.fsf@gitster.g/
