Brian Gernhardt <br...@gernhardtsoftware.com> writes:
> I've been getting a couple of test failures and finally had the time to track
> them down.
>
> t4034-diff-words fails tests "22 diff driver 'bibtex'" and "26
> diff driver 'html'". Bisecting shows that the file started giving
> me errors in commit 8d96e72 "t4034: bulk verify builtin word regex
> sanity", which appears to introduce those tests. I don't see
> anything obviously wrong with the tests and I'm not familiar with
> the diff-words code, so I'm not sure what's wrong.
>
> I am running on OS X 10.8, with Xcode 4.4.1 (llvm-gcc 4.2.1).
>
> Test results follow:
>
> ---------- 8< ----------
>
> expecting success:
> cp "$TEST_DIRECTORY/t4034/bibtex/pre" \
> "$TEST_DIRECTORY/t4034/bibtex/post" \
> "$TEST_DIRECTORY/t4034/bibtex/expect" . &&
> echo "* diff=bibtex" >.gitattributes &&
> word_diff --color-words
>
> --- expect 2012-08-18 05:54:29.000000000 +0000
> +++ output.decrypted 2012-08-18 05:54:29.000000000 +0000
> @@ -8,8 +8,8 @@
> author={Aldous, <RED>D.<RESET><GREEN>David<RESET>},
> journal={Information Theory, IEEE Transactions on},<RESET>
> volume={<RED>33<RESET><GREEN>Bogus.<RESET>},
> - number={<RED>2<RESET><GREEN>4<RESET>},
> + number={4},
> pages={219--223},<RESET>
> - year=<GREEN>1987,<RESET>
> -<GREEN> note={This is in fact a rather funny read since ethernet works well
> in practice. The<RESET> {<RED>1987<RESET><GREEN>\em pre} reference is the
> right one, however.<RESET>}<RED>,<RESET>
> + year=<RED>{1987},<RESET><GREEN>1987,<RESET>
> + note={This is in fact a rather funny read since ethernet works well in
> practice. The {\em pre} reference is the right one, however.}
> }<RESET>
> not ok - 22 diff driver 'bibtex'
Thanks for a report. Off the top of my head, there may be three
possibilities.
(1) The compiled binary of Git is broken on your platform and not
formatting the escape sequence correctly. I somehow think it
is very unlikely, as the code to do so is pretty much platform
agonistic (color.c does not use anything fancy from system
libraries).
(2) The test script, the part that converts the escape sequence to
human readable form, is broken---not written in a portable awk.
(3) The implementation of awk on your platform was broken by your
supplier, with the same infinite wisdom they broke the UTF-8
pathnames on their filesystem implementation with ;-)
Can you help isolating the issue first to see if it is (1) or one of
the other two?
Run "cd t && sh t4034-diff-words -i" to force stop the test upon the
first breakage, and inspect the "output" before the awk script
test_decode_color munges it. Does it show a red number 2 and green
number 4 on the line that begins with "number=" (or if you have an
access to a box on which this test passes, grab the raw output from
it by running this test, and make byte-for-byte comparison)?
--
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
