[PATCH] Use line buffering for standard output

Normally, stdout is fully buffered, unless it refers to a terminal
device. This gives problems when fork() is in play: the buffer is
cloned and output appears twice.

By always setting stdout to line buffering, we make the output work
identically for all output devices.

Signed-off-by: Anders Melchiorsen <redacted>
---

On #git, blix mentioned that running git clone through a pipe made it
output the "Initialized empty" line twice. This seems to be due to
bad interactions between fork() and buffered stdio.

Rather than putting in flushing at all the right places, this
sledgehammer fix simply reverts to line buffering for all output devices.


Anders.


 git.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/git.c b/git.c
index 37b1d76..040b900 100644
--- a/git.c
+++ b/git.c

@@ -421,6 +421,12 @@ int main(int argc, const char **argv)
 	int done_alias = 0;
 
 	/*
+	 * Use line buffering, even if we do not have interactive
+	 * output. Full buffering mixes badly with fork().
+	 */
+	setvbuf(stdout, NULL, _IOLBF, 0);
+
+	/*
 	 * Take the basename of argv[0] as the command
 	 * name, and the dirname as the default exec_path
 	 * if we don't have anything better.

-- 
1.5.6.4

On Sun, 3 Aug 2008, Anders Melchiorsen wrote:

Normally, stdout is fully buffered, unless it refers to a terminal
device. This gives problems when fork() is in play: the buffer is
cloned and output appears twice.

By always setting stdout to line buffering, we make the output work
identically for all output devices.

Please don't.

This is a huge peformance issue for things like

	git log -p > file

where we really want it to be fully buffered.

So please just find the place where we do a fork() without flushing 
pending output...

(We really shouldn't have all that many "fork()" calls left, I thought - 
the Windows stuff means that most of it should be abstracted away. So it's 
not like we're talking about hundreds of sites, there should be just a 
couple).

		Linus