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

["Björn Steinbrink" <B.Steinbrink@gmx.de>]

On 2009.12.09 15:45:36 +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 09, 2009 at 02:30:06PM +0100, Matthieu Moy wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> > 
> > > 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.
> > 
> > Intuitively,
> > 
> >   git rebase --reverse A..B
> > 
> > would mean "take the range A..B, and start applying the patches from
> > B, going in reverse order up to A", like "git log --reverse". So, I'd
> > find it misleading.
> > 
> > Perhaps "git rebase --cherry-pick A..B" would be a better name. No
> > objection for --opposite either.
> 
> I relly like --cherry-pick. Junio, objections to that one?

Hm, there's also (the probably not so well known)
"git rev-list --cherry-pick A...B", which excludes commits that appear
on both A and B and have the same patch id. I'd rather call the rev-list
option a misnomer than the suggested hidden option for rebase, but I'd
call it --cherry-pick-mode or --cherry-picking (like am's hidden "git am
--rebasing"), just to make sure... Of course, it's not _that_ important,
as it's going to be a hidden option, so user confusion is probably not
that much of a concern.

Björn