On Fri, Aug 28, 2015 at 11:27:04AM -0700, Junio C Hamano wrote: > > 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. I think Jonathan's point is that you could pick _one_ active child to show without buffering, while simultaneously buffering everybody else's output. When that finishes, pick a new active child, show its buffer, and then start showing its output in realtime. And so on. So to an observer, it would look like a serial operation, but subsequent operations after the first would magically go much faster (because they'd been working and buffering in the background). And that doesn't require any additional IPC magic (though I am not sure how we get progress in the first place if the child stderr is a pipe...). -Peff -- 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