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

[Jonathan Nieder <jrnieder@gmail.com>]

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.

Even with --no-progress, there is a similar sense of confusion in the
intermixed output.  Error messages are hard to find.  This is a
comment complaint about the current "repo sync -j" implementation.

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/? )==============

That would require more sophisticated inter-process communication than
seems necessary for the first version of parallel "git submodule
update".  For the first version that people use in the wild, showing
output from one of the tasks at a time, simulating a sped-up
sequential implementation, seems useful to me.

In the degenerate case where only one task is running, it reduces to
the current output.  The output is familiar and easy to use.  I quite
like the approach.

My two cents,
Jonathan