Re: [RFC PATCH] Make gitk use --early-output

From: Marco Costalba <mcostalba@gmail.com>
Date: Nov 4, 2007, 11:57 UTC
Message-ID: <e5bfff550711040357w77e85ecfl3f840502a8f2ec38@mail.gmail.com>
In-Reply-To: <18221.42793.38389.359621@cargo.ozlabs.ibm.com>

On 11/4/07, Paul Mackerras <paulus@samba.org> wrote:

>
> So yes, --early-output does imply --topo-order.
>

Thanks, I should have checked myself.

Show 8 quoted lines

> > P.S: Why did you choose not let git log (i.e. Linus) to handle the
> > default number of commits?
> >
> > "--early-output=50" instead of just "--early-output"
>
> Because I was thinking of adding a control in the edit/preferences
> window for it later on.
>

I see. Perhaps this default number could become obsolete very quickly if Linus implements what he has suggested in a similar thread:

"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."

One thing I see playing with this new --early-output feature in qgit is that for small /warm cache repos the list of revisions is already the final one, i.e. the line

"Final output"

appears as the first (and useless in this case) line of the git-log output stream.

If my proposal to teach git-log to check the final output revisions against the already outputted one is accepted then the handling of the above case would come free.

The proposal is that in case early-output has already streamed out 'n' revisions, when the final ones are ready git-log checks the firsts 'n' final output revisions and if they exactly match with the already outputted ones then "Final output" line is skipped and final output stream starts directly from revisions 'n+1'.

Given the statistically very low number of out of order revisions in big repos the above could end up being the common case.

Marco