On Mon, Jul 05, 2021 at 12:47:50AM +0200, Christian Weisgerber wrote:
> Stefan Sperling:
> 
> > I chose to display the number of commits scanned because this allows the
> > user to tell that we're making progress no matter what the result will be.
> > 
> > Failing that, if you don't like your time-based rate limiting, we could
> 
> I mean, I like the result.  I just don't like my code.

Another idea that came to mind is to reduce the amount of progress
updates as the numer of processed commits keeps increasing:

 commits 0 to 9 : report each commit
 commits 10 to 100 : report commits 10, 20, 30, ..., 90, 100
 commits 100 to 1000 : report commits 100, 200, 300, ..., 900, 1000
 commits 1000 onwards: report every 1000 commits
 finally: report the final number of commits processed

Would that work?

> > rate-limit based on the number of times the callback is invoked.
> > We could rate-limit calls to fflush(stdout) in the callback to, say,
> > every 10 times it gets called (where 10 could be optimized according to
> > benchmarks). And add a final fflush(stdout) call when the operation has
> > completed.
> 
> That produces the same amount of output, just in bursts.
> Imagine you are receiving 6.2 MB of output on a 9600 bps console...

Well, there is a cleanup -q flag for a reason.

A 9600 bps console is not going to be very happy even when you run a regular
command like 'got log' or sometimes even 'got diff' without redirecting
the output to a file.