"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > Add --revisions flag to rebase, so that it can be used > to apply an arbitrary range of commits on top > of a current branch. Many people wanted to have "pick many commits onto the current HEAD" and I think it would be a natural, uncontroversial and welcome addition to allow "git cherry-pick A..B". In fact, historically, people who wanted to have "pick many commits" complained that the "rebase" interface was backwards, because it works in the _wrong_ direction for _their_ usecase. Of course, when you _are_ rebasing a branch on top of some other branch, the way "rebase" currently works is the _right_ direction. But I think it is a reasonable thing to _implement_ the feature to range-pick commits reusing the sequencing logic already in "rebase" and "rebase -i". That essentially is what we wanted to do with "git sequencer" that would be a sequencing logic backend shared among rebase, cherry-pick, and perhaps am. So perhaps a good way to move forward is to teach "git cherry-pick A..B" to be a thin wrapper that invokes a new hidden mode of operation added to "rebase" that is not advertised to the end user. I would suggest calling the option to invoke that hidden mode not "--revisions", but "--reverse" or "--opposite" or something of that nature, though. It makes "rebase" work in different direction. -- 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