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

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.

--=20
=C2=B7O=C2=B7  Pierre Habouzit
=C2=B7=C2=B7O                                                madcoder@debia=
n.org
OOO                                                http://www.madism.org