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

On Thu, Aug 14, 2025 at 2:51 PM Junio C Hamano [off-list ref] wrote:

Eric Sunshine [off-list ref] writes:

quoted

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.

I typed that command all one one line; Gmail wrapped the line.

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.

Yes, part of the point of the illustrated test was indeed to
demonstrate lack of deduplication.

By the way, as a real-world developer/user, I do periodically find
myself in situations in which it *is* convenient to ask for the same
piece of information twice (or thrice) because it simplifies
downstream scripting in ad hoc (and not so ad hoc) situations when I
need to manipulate the same value in different ways. In such cases,
asking for the information more than once saves me the trouble of
having to assign the value to a variable, which is handy when the
downstream language or tool doesn't provide variables.

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?

I think Lucas already future-proofed this (and my example copied his
future-proofing) by using `--ref-format=files` with the git-init
invocation.