On Tue, 26 Jun 2007, Jeff King wrote:
>
> 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.
> 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");
}
}
-
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
