Re: [PATCH] git-rev-list: give better diagnostic for failed write
From: Jeff King <hidden>
Date: 2016-06-15 22:43:18
Possibly related (same subject, not in this thread)
- 2016-06-15 · [PATCH] git-rev-list: give better diagnostic for failed write · Jim Meyering <hidden>
- 2016-06-15 · Re: [PATCH] git-rev-list: give better diagnostic for failed write · Linus Torvalds <torvalds@linux-foundation.org>
- 2016-06-15 · Re: [PATCH] git-rev-list: give better diagnostic for failed write · Jim Meyering <hidden>
- 2016-06-15 · Re: [PATCH] git-rev-list: give better diagnostic for failed write · Linus Torvalds <torvalds@linux-foundation.org>
- 2016-06-15 · Re: [PATCH] git-rev-list: give better diagnostic for failed write · Jim Meyering <hidden>
On Mon, Jun 25, 2007 at 03:56:11PM -0700, Linus Torvalds wrote:
quoted hunk ↗ jump to hunk
--- a/log-tree.c +++ b/log-tree.c@@ -408,5 +408,6 @@ int log_tree_commit(struct rev_info *opt, struct commit *commit) shown = 1; } opt->loginfo = NULL; + flush_or_die(stdout, "stdout"); return shown; }
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. 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. :) -Peff