Eric Sunshine <sunshine@xxxxxxxxxxxxxx> 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?
