No activity since 2012, no tests, no chance of ever graduating.

Cc: Jeff King <p...@peff.net>
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
 contrib/diff-highlight/README         | 152 -----------------------------
 contrib/diff-highlight/diff-highlight | 173 ----------------------------------
 2 files changed, 325 deletions(-)
 delete mode 100644 contrib/diff-highlight/README
 delete mode 100755 contrib/diff-highlight/diff-highlight

diff --git a/contrib/diff-highlight/README b/contrib/diff-highlight/README
deleted file mode 100644
index 502e03b..0000000
--- a/contrib/diff-highlight/README
+++ /dev/null
@@ -1,152 +0,0 @@
-diff-highlight
-==============
-
-Line oriented diffs are great for reviewing code, because for most
-hunks, you want to see the old and the new segments of code next to each
-other. Sometimes, though, when an old line and a new line are very
-similar, it's hard to immediately see the difference.
-
-You can use "--color-words" to highlight only the changed portions of
-lines. However, this can often be hard to read for code, as it loses
-the line structure, and you end up with oddly formatted bits.
-
-Instead, this script post-processes the line-oriented diff, finds pairs
-of lines, and highlights the differing segments.  It's currently very
-simple and stupid about doing these tasks. In particular:
-
-  1. It will only highlight hunks in which the number of removed and
-     added lines is the same, and it will pair lines within the hunk by
-     position (so the first removed line is compared to the first added
-     line, and so forth). This is simple and tends to work well in
-     practice. More complex changes don't highlight well, so we tend to
-     exclude them due to the "same number of removed and added lines"
-     restriction. Or even if we do try to highlight them, they end up
-     not highlighting because of our "don't highlight if the whole line
-     would be highlighted" rule.
-
-  2. It will find the common prefix and suffix of two lines, and
-     consider everything in the middle to be "different". It could
-     instead do a real diff of the characters between the two lines and
-     find common subsequences. However, the point of the highlight is to
-     call attention to a certain area. Even if some small subset of the
-     highlighted area actually didn't change, that's OK. In practice it
-     ends up being more readable to just have a single blob on the line
-     showing the interesting bit.
-
-The goal of the script is therefore not to be exact about highlighting
-changes, but to call attention to areas of interest without being
-visually distracting.  Non-diff lines and existing diff coloration is
-preserved; the intent is that the output should look exactly the same as
-the input, except for the occasional highlight.
-
-Use
----
-
-You can try out the diff-highlight program with:
-
----------------------------------------------
-git log -p --color | /path/to/diff-highlight
----------------------------------------------
-
-If you want to use it all the time, drop it in your $PATH and put the
-following in your git configuration:
-
----------------------------------------------
-[pager]
-       log = diff-highlight | less
-       show = diff-highlight | less
-       diff = diff-highlight | less
----------------------------------------------
-
-Bugs
-----
-
-Because diff-highlight relies on heuristics to guess which parts of
-changes are important, there are some cases where the highlighting is
-more distracting than useful. Fortunately, these cases are rare in
-practice, and when they do occur, the worst case is simply a little
-extra highlighting. This section documents some cases known to be
-sub-optimal, in case somebody feels like working on improving the
-heuristics.
-
-1. Two changes on the same line get highlighted in a blob. For example,
-   highlighting:
-
-----------------------------------------------
--foo(buf, size);
-+foo(obj->buf, obj->size);
-----------------------------------------------
-
-   yields (where the inside of "+{}" would be highlighted):
-
-----------------------------------------------
--foo(buf, size);
-+foo(+{obj->buf, obj->}size);
-----------------------------------------------
-
-   whereas a more semantically meaningful output would be:
-
-----------------------------------------------
--foo(buf, size);
-+foo(+{obj->}buf, +{obj->}size);
-----------------------------------------------
-
-   Note that doing this right would probably involve a set of
-   content-specific boundary patterns, similar to word-diff. Otherwise
-   you get junk like:
-
------------------------------------------------------
--this line has some -{i}nt-{ere}sti-{ng} text on it
-+this line has some +{fa}nt+{a}sti+{c} text on it
------------------------------------------------------
-
-   which is less readable than the current output.
-
-2. The multi-line matching assumes that lines in the pre- and post-image
-   match by position. This is often the case, but can be fooled when a
-   line is removed from the top and a new one added at the bottom (or
-   vice versa). Unless the lines in the middle are also changed, diffs
-   will show this as two hunks, and it will not get highlighted at all
-   (which is good). But if the lines in the middle are changed, the
-   highlighting can be misleading. Here's a pathological case:
-
------------------------------------------------------
--one
--two
--three
--four
-+two 2
-+three 3
-+four 4
-+five 5
------------------------------------------------------
-
-   which gets highlighted as:
-
------------------------------------------------------
--one
--t-{wo}
--three
--f-{our}
-+two 2
-+t+{hree 3}
-+four 4
-+f+{ive 5}
------------------------------------------------------
-
-   because it matches "two" to "three 3", and so forth. It would be
-   nicer as:
-
------------------------------------------------------
--one
--two
--three
--four
-+two +{2}
-+three +{3}
-+four +{4}
-+five 5
------------------------------------------------------
-
-   which would probably involve pre-matching the lines into pairs
-   according to some heuristic.
diff --git a/contrib/diff-highlight/diff-highlight 
b/contrib/diff-highlight/diff-highlight
deleted file mode 100755
index c4404d4..0000000
--- a/contrib/diff-highlight/diff-highlight
+++ /dev/null
@@ -1,173 +0,0 @@
-#!/usr/bin/perl
-
-use warnings FATAL => 'all';
-use strict;
-
-# Highlight by reversing foreground and background. You could do
-# other things like bold or underline if you prefer.
-my $HIGHLIGHT   = "\x1b[7m";
-my $UNHIGHLIGHT = "\x1b[27m";
-my $COLOR = qr/\x1b\[[0-9;]*m/;
-my $BORING = qr/$COLOR|\s/;
-
-my @removed;
-my @added;
-my $in_hunk;
-
-while (<>) {
-       if (!$in_hunk) {
-               print;
-               $in_hunk = /^$COLOR*\@/;
-       }
-       elsif (/^$COLOR*-/) {
-               push @removed, $_;
-       }
-       elsif (/^$COLOR*\+/) {
-               push @added, $_;
-       }
-       else {
-               show_hunk(\@removed, \@added);
-               @removed = ();
-               @added = ();
-
-               print;
-               $in_hunk = /^$COLOR*[\@ ]/;
-       }
-
-       # Most of the time there is enough output to keep things streaming,
-       # but for something like "git log -Sfoo", you can get one early
-       # commit and then many seconds of nothing. We want to show
-       # that one commit as soon as possible.
-       #
-       # 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) {
-               local $| = 1;
-       }
-}
-
-# Flush any queued hunk (this can happen when there is no trailing context in
-# the final diff of the input).
-show_hunk(\@removed, \@added);
-
-exit 0;
-
-sub show_hunk {
-       my ($a, $b) = @_;
-
-       # If one side is empty, then there is nothing to compare or highlight.
-       if (!@$a || !@$b) {
-               print @$a, @$b;
-               return;
-       }
-
-       # If we have mismatched numbers of lines on each side, we could try to
-       # be clever and match up similar lines. But for now we are simple and
-       # stupid, and only handle multi-line hunks that remove and add the same
-       # number of lines.
-       if (@$a != @$b) {
-               print @$a, @$b;
-               return;
-       }
-
-       my @queue;
-       for (my $i = 0; $i < @$a; $i++) {
-               my ($rm, $add) = highlight_pair($a->[$i], $b->[$i]);
-               print $rm;
-               push @queue, $add;
-       }
-       print @queue;
-}
-
-sub highlight_pair {
-       my @a = split_line(shift);
-       my @b = split_line(shift);
-
-       # Find common prefix, taking care to skip any ansi
-       # color codes.
-       my $seen_plusminus;
-       my ($pa, $pb) = (0, 0);
-       while ($pa < @a && $pb < @b) {
-               if ($a[$pa] =~ /$COLOR/) {
-                       $pa++;
-               }
-               elsif ($b[$pb] =~ /$COLOR/) {
-                       $pb++;
-               }
-               elsif ($a[$pa] eq $b[$pb]) {
-                       $pa++;
-                       $pb++;
-               }
-               elsif (!$seen_plusminus && $a[$pa] eq '-' && $b[$pb] eq '+') {
-                       $seen_plusminus = 1;
-                       $pa++;
-                       $pb++;
-               }
-               else {
-                       last;
-               }
-       }
-
-       # Find common suffix, ignoring colors.
-       my ($sa, $sb) = ($#a, $#b);
-       while ($sa >= $pa && $sb >= $pb) {
-               if ($a[$sa] =~ /$COLOR/) {
-                       $sa--;
-               }
-               elsif ($b[$sb] =~ /$COLOR/) {
-                       $sb--;
-               }
-               elsif ($a[$sa] eq $b[$sb]) {
-                       $sa--;
-                       $sb--;
-               }
-               else {
-                       last;
-               }
-       }
-
-       if (is_pair_interesting(\@a, $pa, $sa, \@b, $pb, $sb)) {
-               return highlight_line(\@a, $pa, $sa),
-                      highlight_line(\@b, $pb, $sb);
-       }
-       else {
-               return join('', @a),
-                      join('', @b);
-       }
-}
-
-sub split_line {
-       local $_ = shift;
-       return map { /$COLOR/ ? $_ : (split //) }
-              split /($COLOR*)/;
-}
-
-sub highlight_line {
-       my ($line, $prefix, $suffix) = @_;
-
-       return join('',
-               @{$line}[0..($prefix-1)],
-               $HIGHLIGHT,
-               @{$line}[$prefix..$suffix],
-               $UNHIGHLIGHT,
-               @{$line}[($suffix+1)..$#$line]
-       );
-}
-
-# Pairs are interesting to highlight only if we are going to end up
-# highlighting a subset (i.e., not the whole line). Otherwise, the highlighting
-# is just useless noise. We can detect this by finding either a matching prefix
-# or suffix (disregarding boring bits like whitespace and colorization).
-sub is_pair_interesting {
-       my ($a, $pa, $sa, $b, $pb, $sb) = @_;
-       my $prefix_a = join('', @$a[0..($pa-1)]);
-       my $prefix_b = join('', @$b[0..($pb-1)]);
-       my $suffix_a = join('', @$a[($sa+1)..$#$a]);
-       my $suffix_b = join('', @$b[($sb+1)..$#$b]);
-
-       return $prefix_a !~ /^$COLOR*-$BORING*$/ ||
-              $prefix_b !~ /^$COLOR*\+$BORING*$/ ||
-              $suffix_a !~ /^$BORING*$/ ||
-              $suffix_b !~ /^$BORING*$/;
-}
-- 
1.9.2+fc1.27.gbce2056

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to