color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
#!/bin/sh
|
|
|
|
|
|
|
|
test_description='word diff colors'
|
|
|
|
|
|
|
|
. ./test-lib.sh
|
2012-03-14 19:50:21 +00:00
|
|
|
. "$TEST_DIRECTORY"/diff-lib.sh
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
cat >pre.simple <<-\EOF
|
|
|
|
h(4)
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c
|
|
|
|
EOF
|
|
|
|
cat >post.simple <<-\EOF
|
|
|
|
h(4),hh[44]
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
aa = a
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
aeff = aeff * ( aaa )
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
EOF
|
2011-01-11 21:49:57 +00:00
|
|
|
cat >expect.letter-runs-are-words <<-\EOF
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 330b04f..5ed8eff 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1,3 +1,7 @@<RESET>
|
|
|
|
h(4),<GREEN>hh<RESET>[44]
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c<RESET>
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>aa = a<RESET>
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>aeff = aeff * ( aaa<RESET> )
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
EOF
|
2011-01-11 21:49:57 +00:00
|
|
|
cat >expect.non-whitespace-is-word <<-\EOF
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 330b04f..5ed8eff 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1,3 +1,7 @@<RESET>
|
|
|
|
h(4)<GREEN>,hh[44]<RESET>
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c<RESET>
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>aa = a<RESET>
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>aeff = aeff * ( aaa )<RESET>
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
EOF
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
word_diff () {
|
|
|
|
test_must_fail git diff --no-index "$@" pre post >output &&
|
|
|
|
test_decode_color <output >output.decrypted &&
|
|
|
|
test_cmp expect output.decrypted
|
|
|
|
}
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_language_driver () {
|
|
|
|
lang=$1
|
|
|
|
test_expect_success "diff driver '$lang'" '
|
|
|
|
cp "$TEST_DIRECTORY/t4034/'"$lang"'/pre" \
|
|
|
|
"$TEST_DIRECTORY/t4034/'"$lang"'/post" \
|
|
|
|
"$TEST_DIRECTORY/t4034/'"$lang"'/expect" . &&
|
|
|
|
echo "* diff='"$lang"'" >.gitattributes &&
|
|
|
|
word_diff --color-words
|
|
|
|
'
|
|
|
|
}
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success setup '
|
|
|
|
git config diff.color.old red &&
|
|
|
|
git config diff.color.new green &&
|
|
|
|
git config diff.color.func magenta
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success 'set up pre and post with runs of whitespace' '
|
|
|
|
cp pre.simple pre &&
|
|
|
|
cp post.simple post
|
2010-04-14 15:59:06 +00:00
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success 'word diff with runs of whitespace' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 330b04f..5ed8eff 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1,3 +1,7 @@<RESET>
|
|
|
|
<RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
|
|
|
|
|
|
|
|
a = b + c<RESET>
|
|
|
|
|
|
|
|
<GREEN>aa = a<RESET>
|
|
|
|
|
|
|
|
<GREEN>aeff = aeff * ( aaa )<RESET>
|
|
|
|
EOF
|
|
|
|
word_diff --color-words &&
|
|
|
|
word_diff --word-diff=color &&
|
2010-04-14 15:59:06 +00:00
|
|
|
word_diff --color --word-diff=color
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--word-diff=porcelain' '
|
2011-01-11 21:49:57 +00:00
|
|
|
sed 's/#.*$//' >expect <<-\EOF &&
|
|
|
|
diff --git a/pre b/post
|
|
|
|
index 330b04f..5ed8eff 100644
|
|
|
|
--- a/pre
|
|
|
|
+++ b/post
|
|
|
|
@@ -1,3 +1,7 @@
|
|
|
|
-h(4)
|
|
|
|
+h(4),hh[44]
|
|
|
|
~
|
|
|
|
# significant space
|
|
|
|
~
|
|
|
|
a = b + c
|
|
|
|
~
|
|
|
|
~
|
|
|
|
+aa = a
|
|
|
|
~
|
|
|
|
~
|
|
|
|
+aeff = aeff * ( aaa )
|
|
|
|
~
|
|
|
|
EOF
|
2010-04-14 15:59:06 +00:00
|
|
|
word_diff --word-diff=porcelain
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success '--word-diff=plain' '
|
2011-01-11 21:49:57 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
diff --git a/pre b/post
|
|
|
|
index 330b04f..5ed8eff 100644
|
|
|
|
--- a/pre
|
|
|
|
+++ b/post
|
|
|
|
@@ -1,3 +1,7 @@
|
|
|
|
[-h(4)-]{+h(4),hh[44]+}
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
{+aa = a+}
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
{+aeff = aeff * ( aaa )+}
|
|
|
|
EOF
|
|
|
|
word_diff --word-diff=plain &&
|
2010-04-14 15:59:06 +00:00
|
|
|
word_diff --word-diff=plain --no-color
|
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success '--word-diff=plain --color' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 330b04f..5ed8eff 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1,3 +1,7 @@<RESET>
|
|
|
|
<RED>[-h(4)-]<RESET><GREEN>{+h(4),hh[44]+}<RESET>
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c<RESET>
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>{+aa = a+}<RESET>
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>{+aeff = aeff * ( aaa )+}<RESET>
|
|
|
|
EOF
|
2010-04-14 15:59:06 +00:00
|
|
|
word_diff --word-diff=plain --color
|
|
|
|
'
|
|
|
|
|
2009-10-29 10:45:03 +00:00
|
|
|
test_expect_success 'word diff without context' '
|
2011-01-11 21:49:57 +00:00
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 330b04f..5ed8eff 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1 +1 @@<RESET>
|
|
|
|
<RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
|
|
|
|
<CYAN>@@ -3,0 +4,4 @@<RESET> <RESET><MAGENTA>a = b + c<RESET>
|
|
|
|
|
|
|
|
<GREEN>aa = a<RESET>
|
|
|
|
|
|
|
|
<GREEN>aeff = aeff * ( aaa )<RESET>
|
|
|
|
EOF
|
2009-10-28 12:24:30 +00:00
|
|
|
word_diff --color-words --unified=0
|
|
|
|
'
|
|
|
|
|
2009-01-17 16:29:45 +00:00
|
|
|
test_expect_success 'word diff with a regular expression' '
|
2011-01-11 21:49:57 +00:00
|
|
|
cp expect.letter-runs-are-words expect &&
|
2009-01-17 16:29:45 +00:00
|
|
|
word_diff --color-words="[a-z]+"
|
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success 'set up a diff driver' '
|
2009-01-21 04:59:54 +00:00
|
|
|
git config diff.testdriver.wordRegex "[^[:space:]]" &&
|
2011-01-11 21:49:57 +00:00
|
|
|
cat <<-\EOF >.gitattributes
|
|
|
|
pre diff=testdriver
|
|
|
|
post diff=testdriver
|
|
|
|
EOF
|
2009-01-17 16:29:48 +00:00
|
|
|
'
|
|
|
|
|
2009-01-21 03:46:57 +00:00
|
|
|
test_expect_success 'option overrides .gitattributes' '
|
2011-01-11 21:49:57 +00:00
|
|
|
cp expect.letter-runs-are-words expect &&
|
2009-01-17 16:29:48 +00:00
|
|
|
word_diff --color-words="[a-z]+"
|
|
|
|
'
|
|
|
|
|
2009-01-21 03:46:57 +00:00
|
|
|
test_expect_success 'use regex supplied by driver' '
|
2011-01-11 21:49:57 +00:00
|
|
|
cp expect.non-whitespace-is-word expect &&
|
2009-01-17 16:29:48 +00:00
|
|
|
word_diff --color-words
|
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success 'set up diff.wordRegex option' '
|
2009-01-21 04:59:54 +00:00
|
|
|
git config diff.wordRegex "[[:alnum:]]+"
|
2009-01-21 03:46:57 +00:00
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'command-line overrides config' '
|
2011-01-11 21:49:57 +00:00
|
|
|
cp expect.letter-runs-are-words expect &&
|
2009-01-21 03:46:57 +00:00
|
|
|
word_diff --color-words="[a-z]+"
|
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success 'command-line overrides config: --word-diff-regex' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 330b04f..5ed8eff 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1,3 +1,7 @@<RESET>
|
|
|
|
h(4),<GREEN>{+hh+}<RESET>[44]
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c<RESET>
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>{+aa = a+}<RESET>
|
2010-04-14 15:59:06 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>{+aeff = aeff * ( aaa+}<RESET> )
|
|
|
|
EOF
|
2010-04-14 15:59:06 +00:00
|
|
|
word_diff --color --word-diff-regex="[a-z]+"
|
|
|
|
'
|
|
|
|
|
2009-01-21 03:46:57 +00:00
|
|
|
test_expect_success '.gitattributes override config' '
|
2011-01-11 21:49:57 +00:00
|
|
|
cp expect.non-whitespace-is-word expect &&
|
2009-01-21 03:46:57 +00:00
|
|
|
word_diff --color-words
|
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success 'setup: remove diff driver regex' '
|
|
|
|
test_might_fail git config --unset diff.testdriver.wordRegex
|
2009-01-21 03:46:57 +00:00
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_expect_success 'use configured regex' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 330b04f..5ed8eff 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1,3 +1,7 @@<RESET>
|
|
|
|
h(4),<GREEN>hh[44<RESET>]
|
2009-01-21 03:46:57 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
a = b + c<RESET>
|
2009-01-21 03:46:57 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>aa = a<RESET>
|
2009-01-21 03:46:57 +00:00
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
<GREEN>aeff = aeff * ( aaa<RESET> )
|
|
|
|
EOF
|
2009-01-21 03:46:57 +00:00
|
|
|
word_diff --color-words
|
|
|
|
'
|
|
|
|
|
2009-01-17 16:29:45 +00:00
|
|
|
test_expect_success 'test parsing words for newline' '
|
2011-01-11 21:49:57 +00:00
|
|
|
echo "aaa (aaa)" >pre &&
|
|
|
|
echo "aaa (aaa) aaa" >post &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index c29453b..be22f37 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1 +1 @@<RESET>
|
|
|
|
aaa (aaa) <GREEN>aaa<RESET>
|
|
|
|
EOF
|
2009-01-17 16:29:45 +00:00
|
|
|
word_diff --color-words="a+"
|
|
|
|
'
|
|
|
|
|
|
|
|
test_expect_success 'test when words are only removed at the end' '
|
2011-01-11 21:49:57 +00:00
|
|
|
echo "(:" >pre &&
|
|
|
|
echo "(" >post &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
<BOLD>diff --git a/pre b/post<RESET>
|
|
|
|
<BOLD>index 289cb9d..2d06f37 100644<RESET>
|
|
|
|
<BOLD>--- a/pre<RESET>
|
|
|
|
<BOLD>+++ b/post<RESET>
|
|
|
|
<CYAN>@@ -1 +1 @@<RESET>
|
|
|
|
(<RED>:<RESET>
|
|
|
|
EOF
|
2009-01-17 16:29:45 +00:00
|
|
|
word_diff --color-words=.
|
|
|
|
'
|
|
|
|
|
2010-04-14 15:59:06 +00:00
|
|
|
test_expect_success '--word-diff=none' '
|
2011-01-11 21:49:57 +00:00
|
|
|
echo "(:" >pre &&
|
|
|
|
echo "(" >post &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
diff --git a/pre b/post
|
|
|
|
index 289cb9d..2d06f37 100644
|
|
|
|
--- a/pre
|
|
|
|
+++ b/post
|
|
|
|
@@ -1 +1 @@
|
|
|
|
-(:
|
|
|
|
+(
|
|
|
|
EOF
|
2010-04-14 15:59:06 +00:00
|
|
|
word_diff --word-diff=plain --word-diff=none
|
|
|
|
'
|
|
|
|
|
2012-03-14 19:50:21 +00:00
|
|
|
test_expect_success 'unset default driver' '
|
|
|
|
test_unconfig diff.wordregex
|
|
|
|
'
|
|
|
|
|
2011-01-11 21:49:57 +00:00
|
|
|
test_language_driver bibtex
|
|
|
|
test_language_driver cpp
|
|
|
|
test_language_driver csharp
|
|
|
|
test_language_driver fortran
|
|
|
|
test_language_driver html
|
|
|
|
test_language_driver java
|
2011-11-15 20:15:03 +00:00
|
|
|
test_language_driver matlab
|
2011-01-11 21:49:57 +00:00
|
|
|
test_language_driver objc
|
|
|
|
test_language_driver pascal
|
2011-01-18 17:43:43 +00:00
|
|
|
test_language_driver perl
|
2011-01-11 21:49:57 +00:00
|
|
|
test_language_driver php
|
|
|
|
test_language_driver python
|
|
|
|
test_language_driver ruby
|
|
|
|
test_language_driver tex
|
t4034: bulk verify builtin word regex sanity
The builtin word regexes should be tested with some simple examples
against simple issues. Do this in bulk.
Mainly due to a lack of language knowledge and inspiration, most of
the test cases (cpp, csharp, java, objc, pascal, php, python, ruby)
are directly based off a C operator precedence table to verify that
all operators are split correctly. This means that they are probably
incomplete or inaccurate except for 'cpp' itself.
Still, they are good enough to already have uncovered a typo in the
python and ruby patterns.
'fortran' is based on my anecdotal knowledge of the DO10I parsing
rules, and thus probably useless. The rest (bibtex, html, tex) are an
ad-hoc test of what I consider important splits in those languages.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-18 16:17:54 +00:00
|
|
|
|
2011-05-20 17:20:12 +00:00
|
|
|
test_expect_success 'word-diff with diff.sbe' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
diff --git a/pre b/post
|
|
|
|
index a1a53b5..bc8fe6d 100644
|
|
|
|
--- a/pre
|
|
|
|
+++ b/post
|
|
|
|
@@ -1,3 +1,3 @@
|
|
|
|
a
|
|
|
|
|
|
|
|
[-b-]{+c+}
|
|
|
|
EOF
|
|
|
|
cat >pre <<-\EOF &&
|
|
|
|
a
|
|
|
|
|
|
|
|
b
|
|
|
|
EOF
|
|
|
|
cat >post <<-\EOF &&
|
|
|
|
a
|
|
|
|
|
|
|
|
c
|
|
|
|
EOF
|
|
|
|
test_when_finished "git config --unset diff.suppress-blank-empty" &&
|
|
|
|
git config diff.suppress-blank-empty true &&
|
|
|
|
word_diff --word-diff=plain
|
|
|
|
'
|
|
|
|
|
2012-01-12 11:15:33 +00:00
|
|
|
test_expect_success 'word-diff with no newline at EOF' '
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
diff --git a/pre b/post
|
|
|
|
index 7bf316e..3dd0303 100644
|
|
|
|
--- a/pre
|
|
|
|
+++ b/post
|
|
|
|
@@ -1 +1 @@
|
|
|
|
a a [-a-]{+ab+} a a
|
|
|
|
EOF
|
|
|
|
printf "%s" "a a a a a" >pre &&
|
|
|
|
printf "%s" "a a ab a a" >post &&
|
|
|
|
word_diff --word-diff=plain
|
|
|
|
'
|
|
|
|
|
2012-03-14 19:50:21 +00:00
|
|
|
test_expect_success 'setup history with two files' '
|
|
|
|
echo "a b; c" >a.tex &&
|
|
|
|
echo "a b; c" >z.txt &&
|
|
|
|
git add a.tex z.txt &&
|
|
|
|
git commit -minitial &&
|
|
|
|
|
|
|
|
# modify both
|
|
|
|
echo "a bx; c" >a.tex &&
|
|
|
|
echo "a bx; c" >z.txt &&
|
|
|
|
git commit -mmodified -a
|
|
|
|
'
|
|
|
|
|
2012-03-14 18:24:09 +00:00
|
|
|
test_expect_success 'wordRegex for the first file does not apply to the second' '
|
2012-03-14 19:50:21 +00:00
|
|
|
echo "*.tex diff=tex" >.gitattributes &&
|
|
|
|
git config diff.tex.wordRegex "[a-z]+|." &&
|
|
|
|
cat >expect <<-\EOF &&
|
|
|
|
diff --git a/a.tex b/a.tex
|
|
|
|
--- a/a.tex
|
|
|
|
+++ b/a.tex
|
|
|
|
@@ -1 +1 @@
|
|
|
|
a [-b-]{+bx+}; c
|
|
|
|
diff --git a/z.txt b/z.txt
|
|
|
|
--- a/z.txt
|
|
|
|
+++ b/z.txt
|
|
|
|
@@ -1 +1 @@
|
|
|
|
a [-b;-]{+bx;+} c
|
|
|
|
EOF
|
|
|
|
git diff --word-diff HEAD~ >actual &&
|
|
|
|
compare_diff_patch expect actual
|
|
|
|
'
|
|
|
|
|
color-words: change algorithm to allow for 0-character word boundaries
Up until now, the color-words code assumed that word boundaries are
identical to white space characters.
Therefore, it could get away with a very simple scheme: it copied the
hunks, substituted newlines for each white space character, called
libxdiff with the processed text, and then identified the text to
output by the offsets (which agreed since the original text had the
same length).
This code was ugly, for a number of reasons:
- it was impossible to introduce 0-character word boundaries,
- we had to print everything word by word, and
- the code needed extra special handling of newlines in the removed part.
Fix all of these issues by processing the text such that
- we build word lists, separated by newlines,
- we remember the original offsets for every word, and
- after calling libxdiff on the wordlists, we parse the hunk headers, and
find the corresponding offsets, and then
- we print the removed/added parts in one go.
The pre and post samples in the test were provided by Santi Béjar.
Note that there is some strange special handling of hunk headers where
one line range is 0 due to POSIX: in this case, the start is one too
low. In other words a hunk header '@@ -1,0 +2 @@' actually means that
the line must be added after the _second_ line of the pre text, _not_
the first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-17 16:29:44 +00:00
|
|
|
test_done
|