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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Dec 08, 2009 at 12:22:59PM -0800, Junio C Hamano wrote:
> "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.

cherry-pick is a binary though while rebase is a shell script.
Should I just exec git rebase? git-rebase?

-- 
MST