Re: [PATCH v3 2/3] worktree: link worktrees with relative paths

[Junio C Hamano <gitster@pobox.com>]

Caleb White <cdwhite3@pm.me> writes:

> What's the best way to parameterize the worktree tests? I would like
> to run the same tests for both absolute and relative paths and I'm
> not particularly a fan of just copying them all into new *-relative.sh
> files.

What I meant by interoperability tests are a lot smaller scale.

A test that creates worktree/repository pair without the option to
use relative, and then tries to use such a worktree/repository pair
with the option would simulate "how well the newer Git handles an
existing repository", and another test that creates with the option
to use relative and uses the worktree/repository without the option
would simulate "how well existing versions of Git works when seeing
a worktree made with the newer git with the relative option".

By "parameterise", if you mean running a set of worktree/repository
tests without the "relative" option enabled, and run the same set of
tests with the option enabled, you could model it after how t8001
and t8002 (or t5560 and t5561) share a lot of same tests that are in
a file that is included by both of them.  In smaller scale, it is
common to have an ad-hoc construct like:

	for conf in relative absolute
	do
		test_expect_success ... 
		test_expect_success ... 
		test_expect_success ... 
	done

that has bunch of test_expect_success, which may change the
behaviour depending on the value of $conf, not &&-chained inside the
for loop.  You can use a nested loop (one for preparing, the other
for testing the use of worktree) if you want to test the full
matrix.

I do not offhand know if such parametralized tests are necessary in
the context of this change, though.

Thanks.