On Fri, Aug 28, 2015 at 11:41:17AM -0700, Stefan Beller wrote: > > 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...). > > Moving the contents from the pipe to a strbuf buffer which we can grow > indefinitely > (way larger than pipe limits, but the output of a git fetch should be > small enough for that).
Right, clearly we can't rely on pipe buffers to be large enough here (though we _may_ want to rely on tempfiles if we aren't sure that the stdout is bounded in a reasonable way). But what I meant was: the child will only show progress if stderr is a tty, but here it is not. I wonder if we need to set GIT_STDERR_IS_TTY=1 in the parent process, and then respect it in the children (this is similar to what GIT_PAGER_IN_USE does for stdout). -Peff -- 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
