Subject: Re: [PATCH 7/9] fetch: fetch submodules in parallel

From: Junio C Hamano <[email-masked]>
Date: Fri, 28 Aug 2015 11:27:04 -0700

Jonathan Nieder <[email-masked]> writes:

> Junio C Hamano wrote:
>
>> My preference is still (1) leave standard error output all connected
>> to the same fd without multiplexing, and (2) line buffer standard
>> output so that the output is at least readable as a text, in a
>> similar way a log of an irc channel where everybody is talking at
>> the same time.
>
> There is something nice about the immediacy of seeing output from all
> the subprocesses at the same time in that model.
>
> But for commands that show progress like "git clone", "git checkout",
> and "git fetch", it does not work well at all.  They provide output
> that updates itself by putting a carriage return at the end of each
> chunk of output, like this:
>
>  remote: Finding sources:  11% (18/155)           \r
>  remote: Finding sources:  12% (19/155)           \r
>
> With multiple commands producing such output, they will overwrite each
> other's lines, producing a mixture that is confusing and unuseful.

That example also illustrates why it is not a useful to buffer all
of these lines and showing them once.

> Ideally what I as a user want to see is something like what "prove"
> writes, showing progress on the multiple tasks that are taking place
> at once:
>
>  ===(     103;1  0/?  8/?  3/?  11/?  6/?  16/?  1/?  1/? )==============

Tell me how that "buffer all and show them once" helps us to get
near that ideal.

> That would require more sophisticated inter-process communication than
> seems necessary for the first version of parallel "git submodule
> update".

Exactly.  Why waste memory to buffer and stall the entire output
from other processes in the interim solution, then?