From: Stefan Sperling Subject: Re: gotadmin cleanup To: Christian Weisgerber Cc: gameoftrees@openbsd.org Date: Tue, 6 Jul 2021 10:56:56 +0200 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.