Re: multiple-commit cherry-pick?

> 
> 
> On Fri, 14 Nov 2008, Linus Torvalds wrote:
> > 
> > but if you already do
> > 
> > 	gitk a..b
> > 
> > then you're _already_ doing a revision limiter and forcing the revision 
> > walk to be synchronous, so there would be no interactivity downside 
> > between 'a..b' and '{a..b}'.
> 
> Btw, the biggest problem (I think) is actually non-simple ranges and just 
> the _syntax_ of these things.
> 
> It's entirely reasonable to want to group a more complex expression than 
> just a single range. IOW, something like
> 
> 	gitk {..origin/pu ^origin/next} {HEAD~5..HEAD~2}
> 
> to show a union of what is in 'pu' but not master or next, and the 
> symmetrical difference of the current merge. It's a perfectly sensible 
> thing to do. And we _can_ do it right now, just with a nasty syntax:
> 
> 	gitk --no-walk $(git rev-list ..origin/pu ^origin/next) $(git rev-list HEAD~5..HEAD~2)
> 
> actually works. But look again at how nasty it is to parse the '{x}' 
> version, because the '{..}' thing now spans multiple arguments.