Re: [PATCH 2/2] read-cache: fix incorrect count and progress bar stalling

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 15, 2021, 02:32 UTC
Message-ID: <xmqqy2bbyi0a.fsf@gitster.g>
In-Reply-To: <87o8c8z105.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 15 quoted lines

> How does the idea that we show "has been done" make sense when you
> combine the progress.c API with the display_throughput(). I.e. output
> like:
> 	
> 	+Working hard:  50% (1/2)<CR>
> 	+Working hard:  50% (1/2), 1.91 MiB | 195.00 KiB/s<CR>
> 	+Working hard:  50% (1/2), 2.86 MiB | 146.00 KiB/s<CR>
> 	+Working hard:  50% (1/2), 3.81 MiB | 130.00 KiB/s<CR>
> 	+Working hard:  50% (1/2), 3.81 MiB | 97.00 KiB/s, done.
> ...
> That's another reason I'm maintaining that reporting progress as "is
> being done" is the only sane way to look at it, because if you think it's
> "has been done" you preclude the API from being used for cases where you
> e.g. want to download 2 files, each file takes 1 minute, and you want to
> show progress on the item itself.

Sorry, but I do not understand your argument here at all.

If you show "has been completed", when such a thing starts, I'd see for a minute this:

 Downloading (0/2) ... X MiB | Y kiB/s

and then it will switch to

 Downloading (1/2) ... progress ...

and after staring at it for another minute, I'd see

 Downloading (2/2) ... done.

And such an output makes sense to me. It is obvious, at least to me, that the output during the first minute is telling me that it hasn't finished but working hard to turn that "0" into "1" at the pace the throughput thing is showing.