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

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

On Wed, Dec 09, 2009 at 03:01:45PM +0100, Björn Steinbrink wrote:
> 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

OK, --cherry-picking looks fine as well.