Re: multiple-commit cherry-pick?

[Pierre Habouzit <madcoder@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1740 bytes --]

On Fri, Nov 14, 2008 at 05:55:51PM +0000, Linus Torvalds wrote:
> 
> 
> 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. 

That would probably be a job that parseopt could take care of. to some
degree.

Also { } is a poor choice as it's an expansion thingy for many shells.
zsh even refuses ` { a.. b } ` as an argument, pretending there is a
syntax error at the closing brace. [ ] looks like a safer choice, it's
used for shells supporting arrays, but only when stuck after an
identifier which won't be our case ever, so we would be probably safe.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]