Why is git log --cherry-pick not removing equivale

Question

I have been trying to use

git log --no-merges --cherry-pick --right-only master...my-branch

to generate a list of commits that are in the my-branch, but not in master (as per the git-log documentation). However, there are still many equivalent commits that are coming up in the list. If I show them and their patches, there is no difference apart from the commit id.

git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 >patcha
git show c53c7c32dcd84bfa7096a50b27738458e84536d5 >patchb

diff patcha patchb
1c1
< commit 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621
---
> commit c53c7c32dcd84bfa7096a50b27738458e84536d5

And even git patch-id shows them as being equivalent:

git show c53c7c32dcd84bfa7096a50b27738458e84536d5 | git patch-id
2b5504fb9a8622b4326195d88c7a20f29701e62b c53c7c32dcd84bfa7096a50b27738458e84536d5
git show 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621 | git patch-id
2b5504fb9a8622b4326195d88c7a20f29701e62b 16cbd0e47406a4f7acbd6dc13f02d74d0b6a7621

How does git log --cherry-pick not pick these up as duplicates?

Answer 1

I've often wondered if git should always check both, but that's probably a considerable performance hit.

That behavior is now (Git 2.11, Q4 2016) quicker than before.

See commit 7c81040 (12 Sep 2016), and commit 5a29cbc (09 Sep 2016) by Jeff King (peff).
Helped-by: Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit f0a84de, 21 Sep 2016)}

patch-ids: refuse to compute patch-id for merge commit

"git log --cherry-pick" used to include merge commits as candidates to be matched up with other commits, resulting a lot of wasted time. The patch-id generation logic has been updated to ignore merges to avoid the wastage.

[...] we may spend a lot of extra time computing these merge diffs.
In the case that inspired this patch, a "git format-patch --cherry-pick" dropped from over 3 minutes to less than 3 seconds.

Answer 2

Have you merged master into your branch since doing the cherry picks? --cherry-pick works first by matching the commit id, and then if that fails, looking for the patch id. If you've merged master into your branch, then you'll now have the actual commit on your branch and the cherry-picked version. So it'll find the commit id, and then proceed to report the cherry-picked version.

I've often wondered if git should always check both, but that's probably a considerable performance hit.