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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Aug 14, 2025, 22:05 UTC
Message-ID: <CAPig+cSZnfG7NDCGDDnFvtwS4hpcGkmVKA0hPhLALmXj=0Zbbw@mail.gmail.com>
In-Reply-To: <xmqqfrdt3feh.fsf@gitster.g>

On Thu, Aug 14, 2025 at 2:51 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 16 quoted lines

> Eric Sunshine <sunshine@sunshineco.com> writes:
> > 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.

Show 5 quoted lines

> 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.