Jonathan Nieder <jrnie...@gmail.com> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
