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

From: Caleb White <cdwhite3@pm.me>
Date: Oct 9, 2024, 19:19 UTC
Message-ID: <oUBKv4JI3Bf1nqAFU_C-HDl5vkZC6mg8mb5F0HB7akXC6n0T1ddV0LiOCqY_AGHCyr9_W7gs2EyTGqIihz89ciBbL61UFwznnHcYRNzfGLI=@pm.me>
In-Reply-To: <xmqqy12xqehd.fsf@gitster.g>

> Caleb White cdwhite3@pm.me writes:
>

Show 5 quoted lines

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

Show 8 quoted lines

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

Show 7 quoted lines

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

Show 7 quoted lines

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

Show 6 quoted lines

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

Ah, I see what you mean, thank you for the details! I'll be sure to look at the examples and try to determine which would be the best paths forward.

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

I can already tell you that this particular case is not going to work because existing versions of git expect the path to be absolute. Most of the changes in this patch revolve around properly reading/handling the relative paths, not writing the relative paths.

Best,