Re: [PATCH 7/9] fetch: fetch submodules in parallel
- From
Jeff King <peff@peff.net>
- Date
- Aug 28, 2015, 18:44 UTC
- Message-ID
- <20150828184405.GA17721@sigill.intra.peff.net>
- In-Reply-To
- <CAGZ79kZALSJ9oY+6ZwyQ9CPFiV-AAq7c-r9mxw3N+gvsDw8m4A@mail.gmail.com>
On Fri, Aug 28, 2015 at 11:41:17AM -0700, Stefan Beller wrote:
Show 12 quoted lines
> > 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