Re: multiple-commit cherry-pick?

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 14, 2008, 17:55 UTC
Message-ID: <alpine.LFD.2.00.0811140945000.3468@nehalem.linux-foundation.org>
In-Reply-To: <alpine.LFD.2.00.0811140936050.3468@nehalem.linux-foundation.org>

On Fri, 14 Nov 2008, Linus Torvalds wrote:

Show 8 quoted lines

> 
> 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