Re: [PATCH RFC] rebase: add --revisions flag

[Junio C Hamano <gitster@pobox.com>]

"Michael S. Tsirkin" <mst@redhat.com> 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.