Martin von Zweigbergk <> 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?

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to