Re: multiple-commit cherry-pick?

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 14, 2008, 17:41 UTC
Message-ID: <alpine.LFD.2.00.0811140936050.3468@nehalem.linux-foundation.org>
In-Reply-To: <7v1vxeb4il.fsf@gitster.siamese.dyndns.org>

On Fri, 14 Nov 2008, Junio C Hamano wrote:

Show 10 quoted lines

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> 
> > So we could make a '{ }' in the argument space basically do a SHA1 
> > expansion of the range inside, and imply --no-walk. It's _not_ entirely 
> > trivial, because we'd need to handle the fact that object flags are 
> > sticky, and clear them in between invocations of multiple ranges, but it's 
> > not _fundmanetally_ difficult. It's just that somebody would need to do 
> > it.
> 
> Wouldn't you lose the nice streaming output (iow short latency)?

Oh, absolutely. So the '{x}' format would be not be a replacement for non-{} format - it would be an addition to.

But it's no different from 'a..b' in that sense: anything that sets 'revs->limited' automatically forces a synchronous revision walk. So you'd be crazy to do

	gitk {HEAD}

because
 (a) there would be no point
 (b) it indeed loses the streaming data and would become synchronous.

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}'.

		Linus