Subject: Re: [GSoC PATCH v9 3/5] repo: add the field layout.bare

From: Junio C Hamano <[email-masked]>
Date: Thu, 14 Aug 2025 11:51:50 -0700

Eric Sunshine <[email-masked]> writes:

>> test_expect_success 'the values are returned in the same order they were requested' '
>>         printf "references.format=files\nlayout.bare=false\n" >expected1 &&
>>         printf "layout.bare=false\nreferences.format=files\n" >expected2 &&
>>         git init --ref-format=files same-order &&
>>         git -C same-order repo info references.format layout.bare >actual1 &&
>>         git -C same-order repo info layout.bare references.format >actual2 &&
>>         test_cmp expected1 actual1 &&
>>         test_cmp expected2 actual2
>> '
>
> Rather than the above, I think a more satisfactory and meaningful test would be:
>
>     test_expect_success 'values returned in order requested' '
>         cat >expect <<-\EOF &&
>         layout.bare=false
>         references.format=files
>         layout.bare=false
>         EOF
>         git init --ref-format=files ordered &&
>         git -C ordered repo info layout.bare references.format
> layout.bare >actual &&
>         test_cmp expect actual
>     '

I do not think the second "layout.bare" should be line-wrapped.

Your point that it is more obvious when the expectations are shown
in HERE-doc may be valid.  Overly long printf with \n indeed is
harder to follow.  Even though there is no reason for a real user to
do so, asking for the same piece of information twice would
demonstrate that there is no deduplication.

I also care about future-proofing, though.  When Git is built with
WITH_BREAKING_CHANGES=YesPlease, this test would break as the
default reference backend will be reftable in that alternate world,
wouldn't it?