Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > Stefan Beller wrote: >> On Thu, Aug 27, 2015 at 6:14 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > >>> This makes use of the new task queue and the syncing feature of >>> run-command to fetch a number of submodules at the same time. >>> >>> The output will look like it would have been run sequential, >>> but faster. >> >> And it breaks the tests t5526-fetch-submodules.sh as the output is done >> on stderr only, instead of putting "Fetching submodule <submodule-path> >> to stdout. :( >> >> I guess combining stdout and stderr is not a good strategy after all now. > > IMHO the "Fetching submodule <submodule-path>" output always should have > gone to stderr. It is not output that scripts would be relying on --- > it is just progress output. > > So a preliminary patch doing that (and updating tests) would make sense > to me. Sounds good. I personally do not think the "we still do all the output from a single process while blocking output from others" buffering implemented in this n-th round (by the way, please use [PATCH v$n N/M]) is worth doing, though. It does not make the output machine parseable, because the reader does not get any signal in what order output of these subprocesses arrive anyway. The payload does not even have "here is the beginning of output from the process that handled the submodule X" to delimit them. 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html