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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jun 26, 2007, 17:12 UTC
Message-ID: <alpine.LFD.0.98.0706261006570.8675@woody.linux-foundation.org>
In-Reply-To: <20070626090605.GA4349@coredump.intra.peff.net>

On Tue, 26 Jun 2007, Jeff King wrote:

Show 5 quoted lines

> 
> I think flushing here is a good change regardless of the error checking.
> Sometimes, when you are severely limiting commits, the whole output is
> smaller than the buffer, and you end up waiting a long time for any
> output even though your answer may have been found immediately.

Exactly. That's why it was done in git-rev-list, and why it's good to do in "git log" too.

The slowdown worries me a bit, but it's only noticeable with *lots* of output - ie no path limiting (and no diffs - the diff generation becomes the bottleneck if you do diffs). So the flushing slows down a case that we do ridiculously well right now, so I doubt anybody will really care.

It's more a benchmarking issue: "we can show the whole log of the kernel in under two seconds", and it didn't slow down *that* much.

Show 5 quoted lines

> For example, 'git-whatchanged -Sfoo' when 'foo' was introduced in the
> last couple of commits (but wasn't referenced before) will have to
> calculate diffs on all of history before producing output. Flushing
> after every commit restores the illusion that git provides your answer
> instaneously. :)

On that note, it should probably also do it for the incremental output of git blame.

		Linus
---

diff --git a/builtin-blame.c b/builtin-blame.c
index f7e2c13..86ab6c7 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1459,6 +1459,7 @@ static void found_guilty_entry(struct blame_entry *ent)
 				printf("boundary\n");
 		}
 		write_filename_info(suspect->path);
+		flush_or_die(stdout, "stdout");
 	}
 }