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