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? 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
