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@xxxxxxxxx> 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. -- 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