Re: [PATCH] git-rev-list: give better diagnostic for failed write

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 26, 2007, 22:32 UTC
Message-ID: <alpine.LFD.0.98.0706261528130.8675@woody.linux-foundation.org>
In-Reply-To: <20070626220440.GB27828@thunk.org>

On Tue, 26 Jun 2007, Theodore Tso wrote:

Show 8 quoted lines

> On Tue, Jun 26, 2007 at 10:32:23AM -0700, Linus Torvalds wrote:
> > But we actually _do_ want fully buffered from a performance angle. 
> > Especially for the big stuff, which is usually the *diffs*, not the commit 
> > messages. Not so much an issue with git-rev-list, but with "git log -p" 
> > you would normally not want it line-buffered, and it's actually much nicer 
> > to let it be fully buffered and then do a flush at the end.
> 
> Well, sometimes we do and sometimes we don't right?

No.

We basically _never_ want "line buffered" or "unbuffered", which is what stdio knows how to do. That sucks in _all_ cases.

What we want is "fully buffered" for plain files, and "record buffered" for anything else (where a "record" is basically the "commit + optional diff").

We can get the record buffered by adding the fflush() calls, but the thing is, we'd want to _avoid_ that if it was a file. It's just that there is no way to set that kind of flag portably with stdio, we'd have to carry it around _separately_ from stdio, which is a big pain.

But if we decide that this only matters with stdout (which currently is what the patches have done), we could of course just make it a single global variable (like "stdout" itself already is). Then we could just make git.c start out by testing stdout at startup and setting the global variable.

		Linus