On Fri, 14 Nov 2008, Linus Torvalds wrote:
quoted text
> 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html