Thread (58 messages) 58 messages, 3 authors, 2019-12-20

Re: [PATCH v2 13/16] t1501: remove use of `test_might_fail cp`

From: Eric Sunshine <hidden>
Date: 2019-12-19 22:53:11

On Thu, Dec 19, 2019 at 5:22 PM Denton Liu [off-list ref] wrote:
The test_must_fail() family of functions (including test_might_fail())
should only be used on git commands. Replace test_might_fail() with
test_non_git_might_fail().

The `test_might_fail cp` line was introduced in 466e8d5d66 (t1501: fix
test with split index, 2015-03-24). It is necessary because there might
exist some index files in `repo.git/sharedindex.*` and, if they exist,
we want to copy them over. However, if they don't exist, we don't want
to error out because we expect that possibility. As a result, we want to
keep the "might fail" semantics so we use test_non_git_might_fail().
Thanks for adding this paragraph to help the reader understand why you
chose this transformation. However...
quoted hunk ↗ jump to hunk
Signed-off-by: Denton Liu <redacted>
---
diff --git a/t/t1501-work-tree.sh b/t/t1501-work-tree.sh
@@ -350,7 +350,7 @@ test_expect_success 'Multi-worktree setup' '
        cp repo.git/HEAD repo.git/index repo.git/repos/foo &&
-       test_might_fail cp repo.git/sharedindex.* repo.git/repos/foo &&
+       test_non_git_might_fail cp repo.git/sharedindex.* repo.git/repos/foo &&
I can't say I'm a fan of patch 1 introducing the function
test_non_git_might_fail() for this one particular case. I'd rather see
this case follow existing precedence by being written this way:

    { cp repo.git/sharedindex.* repo.git/repos/foo || :; } &&

which is the idiomatic way this sort of thing is handled in existing tests.

While it's true that it may look a bit cryptic to people new to shell
scripting, as with any idiom, it's understood at a glance by people
familiar with it. That bit about "at a glance" is important: it's much
easier to comprehend idiomatic code than code which you have to spend
a lot of time _reading_ (and "test_non_git_might_fail" is quite a
mouthful, or eyeful, or something, which takes a lot more effort to
read and understand).
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help