Martin von Zweigbergk [off-list ref] writes:
After patch 7/7, cherry is used instead of rev-list. Ideally, I would
have liked to teach "git rev-list --cherry-pick" to somehow use a
<limit> just like cherry does, but I couldn't think of a generic way
of doing that (in this case, we want to say something like "range
a..b, but drop commits that are equivalent to any in b..c"). I
actually don't remember if I gave up because I couldn't think of a
sensible way of specifying ranges like that, or if I just ran out of
time (not familiar with the revision-walking code).
Why not use patch-id output instead, then? Grab patch-id for
commits b..c to make a mapping from patch-id to commits, do the same
for a..b and use the mapping to filter?