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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
