On Thu, Dec 19, 2019 at 6:18 PM Denton Liu [off-list ref] wrote:

On Thu, Dec 19, 2019 at 05:52:56PM -0500, Eric Sunshine wrote:

quoted

[...] I'd rather see:
    { 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_ [...]

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.

I wouldn't say that the idiom "looks nicer", but rather that it has
value specifically because it is an idiom, therefore it reduces
cognitive load (as explained above).

Idioms aside, the new function test_non_git_might_fail() may increase
cognitive load because the reader needs to remember its purpose and
behavior since it's a black box compared to the open-coded version,
yet adds no actual value. Compare that with, say, test_must_fail()
which not only adds value but would significantly increase cognitive
load if open-coded, thus is well justified. That's not to say that
one-liner functions can't necessarily have value; a well named
function or one which introduces an important abstraction may very
well be worthwhile, but I can't convince myself that
test_non_git_might_fail() succeeds in that way.

So, to answer your question, my preference leans toward open-coding this.