Re: What's cooking in git.git (Jun 2010, #02; Wed, 16)

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

2010/6/17 Junio C Hamano <gitster@pobox.com>:

>> * ab/i18n (2010-06-15) 3 commits
>>  . Add initial C, Shell and Perl gettext translations
>>  . fixup! Add infrastructure
>>  . Add infrastructure for translating Git with gettext
>
> I haven't got around to fix conflicts merging this with various other
> topics yet.

If you need some help with that I could produce a series which merged
those commits with various topics. What should they be merged against?

>> * ab/tap (2010-06-09) 4 commits
>>  - We use TAP so the Perl test can run without scaffolding
>>  - Skip tests in a way that makes sense under TAP
>>  - Merge branch 'jc/t9129-any-utf8' into ab/tap
>>  - Make test-lib.sh emit valid TAP format
>>  (this branch uses jc/t9129-any-utf8.)
>
> I was not sure why TAP is worth the trouble, and I still am not sure.

One way of looking at it is this: If we were writing the test-lib
today, why would we pick this form:

    *   ok 1: sigchain works

Over this:

    ok 1 - sigchain works

When the latter automatically gives us interoperability with a huge
library of existing tools at no cost, and the former gains us nothing.

That's all the TAP series does, change test output so that it conforms
to a standard format, instead of our own ad-hoc format.

It gains us a lot in machine readable test output, and costs us
nothing. Actually less than nothing because some ad-hoc code in the
test-lib is replaced by test-lib<->Perl interop via TAP.

That interop will come in handy down the line with more Perl tests
(e.g. from the gettext series), and more so when things like Gitweb
(hopefully) get tests of their own now that they're being modularized.