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@xxxxxxxxxx
OOO http://www.madism.org
Attachment:
pgpwSKL2VJEFa.pgp
Description: PGP signature
