Enhance --early-output format
commit252a7c02354a3e2825cfde3c5053a04acc07be9c
authorLinus Torvalds <torvalds@linux-foundation.org>
Sun, 4 Nov 2007 20:12:05 +0000 (4 12:12 -0800)
committerJunio C Hamano <gitster@pobox.com>
Mon, 5 Nov 2007 22:28:53 +0000 (5 14:28 -0800)
tree0a0d349a0299800c1791a32771d664f87eee20ae
parentcdcefbc971d8fcdd293750af7571d4c715f86964
Enhance --early-output format

This makes --early-output a bit more advanced, and actually makes it
generate multiple "Final output:" headers as it updates things
asynchronously. I realize that the "Final output:" line is now illogical,
since it's not really final until it also says "done", but

It now _always_ generates a "Final output:" header in front of any commit
list, and that output header gives you a *guess* at the maximum number of
commits available. However, it should be noted that the guess can be
completely off: I do a reasonable job estimating it, but it is not meant
to be exact.

So what happens is that you may get output like this:

 - at 0.1 seconds:

Final output: 2 incomplete
.. 2 commits listed ..

 - half a second later:

Final output: 33 incomplete
.. 33 commits listed ..

 - another half a second after that:

Final output: 71 incomplete
.. 71 commits listed ..

 - another half second later:

Final output: 136 incomplete
.. 100 commits listed: we hit the --early-output limit, and
.. will only output 100 commits, and after this you'll not
.. see an "incomplete" report any more since you got as much
.. early output as you asked for!

 - .. and then finally:

Final output: 73106 done
.. all the commits ..

The above is a real-life scenario on my current kernel tree after having
flushed all the caches.

Tested with the experimental gitk patch that Paul sent out, and by looking
at the actual log output (and verifying that my commit count guesses
actually match real life fairly well).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-log.c
revision.c
revision.h