Re: [PATCH v2 13/16] t1501: remove use of `test_might_fail cp`
- From
Denton Liu <liu.denton@gmail.com>
- Date
- Dec 19, 2019, 23:19 UTC
- Message-ID
- <20191219231940.GA67903@generichostname>
- In-Reply-To
- <CAPig+cQuPDDun3NxnTwvmjo9zvPzSq+5f2utkHkS0f1c1Nwbvg@mail.gmail.com>
Hi Eric,
On Thu, Dec 19, 2019 at 05:52:56PM -0500, Eric Sunshine wrote:
Show 21 quoted lines
> > 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).The reason why I chose to do this was because I found myself writing the above many times in (currently unsent) later test cases that I cleaned up. As a result, I felt like it could be wrapped up more nicely with a helper function. That being said, if you think that open coding the idiom looks nicer, I can reroll to inline it.