Re: multiple-commit cherry-pick?

[Linus Torvalds <torvalds@linux-foundation.org>]

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. 

			Linus