On Fri, Aug 28, 2015 at 11:44 AM, Jeff King <peff@xxxxxxxx> wrote: > 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. Oh, I forgot about that. > > 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). The use of GIT_PAGER_IN_USE looks straightforward to me. I'll try to add GIT_STDERR_IS_TTY then. > > -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