Re: Test failures in t4034

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 19, 2012, 06:12 UTC
Message-ID: <7v7gsvquk8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <80B6C6EE-130C-48C3-BBBB-5FCD1E7EFDEF@gernhardtsoftware.com>

Brian Gernhardt <brian@gernhardtsoftware.com> writes:

Show 37 quoted lines

> 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)?