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

["Marco Costalba" <mcostalba@gmail.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.

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