Re: [REPLACEMENT PATCH 2/2] Add "--early-output" log flag for interactive GUI use

From: Paul Mackerras <paulus@samba.org>
Date: Nov 4, 2007, 07:10 UTC
Message-ID: <18221.28744.805398.598809@cargo.ozlabs.ibm.com>
In-Reply-To: <alpine.LFD.0.999.0711032234030.15101@woody.linux-foundation.org>

Linus Torvalds writes:

Show 8 quoted lines

> > How hard would it be to put the total number of commits on that "Final
> > output" line?  That would be useful for me.
> 
> Not hard. I think we basically have it anyway. The reason I didn't do it 
> is that there's actually multiple numbers: there's the number of primary 
> ("interesting") commits, and then there are the "others", ie the edge 
> things etc. So the number I'd pick would be the number of actual 
> interesting commits, no edges, no nothing. Or what?

Any of those numbers is probably good enough for a progress bar, but ideally it would be the total number that you are going to output. So, with --boundary it would include the edge commits, otherwise it would just be the interesting commits, I think.

Show 6 quoted lines

> One other thing I was thinking of was also to perhaps allow multiple 
> partial early-output things, in case we get just 5 commits in the first 
> 0.1 seconds, then 50 in the first second, and 200 after 2 seconds.. I can 
> well imagine getting the full list taking a long time over a network 
> filesystem (somebody mentioned samba), and maybe having just a single 
> trigger is too inflexible.

In fact gitk won't mind if you give it multiple occurrences of "Final output", as long as you start from the beginning again after each occurrence. So having multiple triggers is certainly doable as far as gitk is concerned. Later on we could optimize that by having git log match up how many initial commits are the same in both the new list and the old list, and have it output that rather than the N commits that were the same as last time.

Paul.