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

From: Theodore Tso <tytso@mit.edu>
Date: Jun 26, 2007, 22:04 UTC
Message-ID: <20070626220440.GB27828@thunk.org>
In-Reply-To: <alpine.LFD.0.98.0706261024210.8675@woody.linux-foundation.org>

On Tue, Jun 26, 2007 at 10:32:23AM -0700, Linus Torvalds wrote:

Show 5 quoted lines

> 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? Some of it depends on how large the *stuff* we are dumping out (diffs vs. commit objects), and what the receiving process on the other bit of the pipeline is doing with the data --- is it doing some kind of statistical reduction (git-rev-log .. | wc -l) versus some kind of asynchronous processing (git-rev-log as used by gitk).

So maybe the answer is that when outputing to a file, we always use full stdio buffering, and in other cases there should be some intelligent defaults plus command-line overrides. So when we emit lists of commit identifiers, it should probably be line buffered, and if it is diffs, it should probably be fully buffered, etc.?

						- Ted