Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Dec 30, 2009, 19:46 UTC
- Message-ID
- <7v1vic1bzh.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20091230224122.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Junio, could you tell us what happened to this thread?
I didn't feel I had enough energy to read the commit log message after seeing it was badly linewrapped and didn't have a sign-off, so I didn't read it.
I've read it now; it is unclear from the proposed commit log message how this fits in the larger picture. Presumably this change is meant to be useful when driving update-index through --stdin? To see if I got the intention right, let me try paraphrasing it...
update-index: flush standard output after each action is reported
A scripted Porcelain that runs "git update-index --stdin" might want
to use a bidirectional pipe, while feeding one path at a time and
reading the output from report() every time after feeding a path. Such a Porcelain would deadlock if the standard output is not flushed
after report().I don't know if the above is what Sebastian meant, though..
An obvious question, when phrased this way, is "what impact does this change have for scripted Porcelains that don't use bi-di pipe?" I think the answer would be "The I/O overhead for flushing would increase", but I don't know if it would be "... would increase but it is still negligible" or "... would increase too much to make it noticeably or unusably slow especially if it feeds hundreds of paths". If it is the latter, this may need to be controlled by another command line option.
Sebastian, care to redo the justification, make it a bit more readable, and add your sign-off?
Thanks.