Re: [BUG] multi-commit cherry-pick messes up the order of commits

Jonathan Nieder <jrnieder@gmail.com> writes:

Revision ranges are not defined as a union of sets, but a single set as a range between zero or more bottom (UNINTERESTING) commits and zero or more top commits, the ones reachable from the top but not from the bottom, so the above will work as if you said "^master ^maint master next", which is the same as "master..next" (if you assume all of "maint" is contained in "master" all of which is contained in "next", of course).

And it is not likely to change soon.

In the longer term (or in an alternate universe where we were inventing Git from scratch today without any existing users), we may want to revamp the revision machinery, taking advantage of the recent addition of the "cmdline" facility to it, so that we would walk ranges "master..next" and "maint..master" independently, clearing the object flags as needed between the separate traversals as needed, and then take a union of these ranges, before returning results from get_revision() calls.