Jeff King wrote: > I am tempted to suggest [...] > That would make all of these work as most people would > expect: > > git cherry-pick A B C > git cherry-pick A..B > git cherry-pick A..B B..C > > but would be a regression for: > > git cherry-pick B ^A > > versus the current code. I suspect that the latter form is not all that > commonly used, though, and certainly I would accept it as a casualty of > making the "A B C" form work. My only hesitation is that it is in fact a > regression. I find myself using such complicated expressions as list-revs-to-skip | xargs git cherry-pick --cherry-pick --right-only HEAD...topic --not so yeah, that would be a pretty serious loss in functionality. However, moving to something like the far future semantics that Junio hinted at, for cherry-pick/revert and other --no-walk style commands only, would not be a regression for me. The multi-pick feature is still young, and I _suspect_ changing the meaning of A..B B..C for it would not inconvenience anybody. I would even welcome a change in the meaning of B ^A: the most intuitive thing for it to do would be to cherry-pick the single commit B when and only when it is not an ancestor of A. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html