]> git.ipfire.org Git - thirdparty/git.git/commitdiff
diff-highlight: correctly match blank lines for flush
authorJeff King <peff@peff.net>
Tue, 22 Sep 2020 05:00:33 +0000 (01:00 -0400)
committerJunio C Hamano <gitster@pobox.com>
Tue, 22 Sep 2020 05:33:28 +0000 (22:33 -0700)
We try to flush the output from diff-highlight whenever we see a blank
line. That lets you see the output for each commit as soon as it is
generated, even if Git is still chugging away at a diff, or traversing
to find the next commit.

However, our "blank line" match checks length($_). That won't ever be
true, because we haven't chomped the line ending. As a result, we never
flush. Instead, let's use a simple regex which handles line endings in
with the end-of-line marker.

This has been broken since the initial version in 927a13fe87 (contrib:
add diff highlight script, 2011-10-18). Probably nobody noticed because:

  - most output is big enough, or comes fast enough, that it flushes
    anyway. And it can be difficult to notice the difference between
    "show a commit, then pause" and "pause, then show two commits". I
    only noticed because I was viewing "git log" output on a repo with a
    very slow textconv filter.

  - if stdout is going to the terminal (and not another pager like
    less), then the flush isn't necessary. So any manual testing would
    show it appearing to work.

You can easily see the difference with something like:

  echo '* diff=slow' >>.gitattributes
  git -c diff.slow.textconv='sleep 1; cat' \
      -c pager.log='diff-highlight | less' \
      log -p

That should generate one commit every second or so (more if it touches
multiple files), but without this patch it waits for many seconds before
generating several pages of output.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
contrib/diff-highlight/DiffHighlight.pm

index e2589922a659641526b8d946ccc06f87e9731de2..376f577737591e26a118718a87945500ea621c95 100644 (file)
@@ -112,7 +112,7 @@ sub handle_line {
        # Since we can receive arbitrary input, there's no optimal
        # place to flush. Flushing on a blank line is a heuristic that
        # happens to match git-log output.
-       if (!length) {
+       if (/^$/) {
                $flush_cb->();
        }
 }