Re: [PATCH v2 15/21] t1414: mark corruption test with REFFILES

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

On Tue, Apr 27 2021, Han-Wen Nienhuys via GitGitGadget wrote:

> From: Han-Wen Nienhuys <hanwen@google.com>
>
> The reftable format guarantees that reflog entries are well-formed
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
> ---
>  t/t1414-reflog-walk.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t1414-reflog-walk.sh b/t/t1414-reflog-walk.sh
> index 80d94704d012..72a5ac61a520 100755
> --- a/t/t1414-reflog-walk.sh
> +++ b/t/t1414-reflog-walk.sh
> @@ -119,7 +119,7 @@ test_expect_success 'min/max age uses entry date to limit' '
>  	test_cmp expect actual
>  '
>  
> -test_expect_success 'walk prefers reflog to ref tip' '
> +test_expect_success REFFILES 'walk prefers reflog to ref tip' '
>  	head=$(git rev-parse HEAD) &&
>  	one=$(git rev-parse one) &&
>  	ident="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE" &&

Isn't the point of this test added in 7cf686b9a8 (t1414: document some
reflog-walk oddities, 2017-07-07) to test what we do not when the reflog
isn't well formed, but when the reflog and branch history disagree about
what the latest tip is?

Perhaps reftable is going to guarantee that that'll never happen via
some transaction mechanism (I'm not sure), but if I'm right then I think
it's worth at least calling out that difference in the commit message
and/or modified test description.

Not a big deal, but this also makes me somewhat question the name
"REFFILES" as a prereq if we really mean (as we are in the first test
that uses this) "we don't need this under reftable, specifically".

Maybe I'm overthinking things and it's stupid to split these up, as we
have no other planned ref backend, but for any such future test backend
/ readability I'd find it much easier to grok if we clearly
deliniate/use REFFILES for tests that really are testing the ref files
backend specifically, v.s. say a !REFTABLE for things that we're
skipping because REFTABLE in particular makes certain guarantees we can
count on. Say that the reflog and branch is never out of sync.

Of course this also uses ref .. files, anyway, just food for thought.