Why is git log --cherry-pick not removing equivalent commits?

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.

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.

---

And with Git 2.31 (Q1 2021), it is fixed: when more than one commit with the same patch ID appears on one side, "git log --cherry-pick A...B"^(man) now does exclude them all when a commit with the same patch ID appears on the other side.