[PATCH] t4205: don't exit test script on failure

[PATCH] t4205: don't exit test script on failure

[René Scharfe]

Only abort the individual check instead of exiting the whole test script
if git show fails.  Noticed with GIT_TEST_PASSING_SANITIZE_LEAK=check.

Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
---
Formatted with --function-context for easier review.
ac52d9410e (t4205: cover `git log --reflog -z` blindspot,
2019-11-19) added the exit call.

 t/t4205-log-pretty-formats.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index e448ef2928..0404491d6e 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -154,12 +154,12 @@ done
 test_expect_success 'NUL termination with --reflog --pretty=oneline' '
 	revs="$(git rev-list --reflog)" &&
 	for r in $revs
 	do
 		git show -s --pretty=oneline "$r" >raw &&
-		cat raw | lf_to_nul || exit 1
+		cat raw | lf_to_nul || return 1
 	done >expect &&
 	# the trailing NUL is already produced so we do not need to
 	# output another one
 	git log -z --pretty=oneline --reflog >actual &&
 	test_cmp expect actual
 '
--
2.30.2

Re: [PATCH] t4205: don't exit test script on failure

[Ævar Arnfjörð Bjarmason]

On Thu, Dec 01 2022, René Scharfe wrote:

> Only abort the individual check instead of exiting the whole test script
> if git show fails.  Noticed with GIT_TEST_PASSING_SANITIZE_LEAK=check.
>
> Helped-by: Eric Sunshine <sunshine@sunshineco.com>
> Signed-off-by: René Scharfe <l.s.r@web.de>
> ---
> Formatted with --function-context for easier review.
> ac52d9410e (t4205: cover `git log --reflog -z` blindspot,
> 2019-11-19) added the exit call.
>
>  t/t4205-log-pretty-formats.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
> index e448ef2928..0404491d6e 100755
> --- a/t/t4205-log-pretty-formats.sh
> +++ b/t/t4205-log-pretty-formats.sh
> @@ -154,12 +154,12 @@ done
>  test_expect_success 'NUL termination with --reflog --pretty=oneline' '
>  	revs="$(git rev-list --reflog)" &&
>  	for r in $revs
>  	do
>  		git show -s --pretty=oneline "$r" >raw &&
> -		cat raw | lf_to_nul || exit 1
> +		cat raw | lf_to_nul || return 1
>  	done >expect &&
>  	# the trailing NUL is already produced so we do not need to
>  	# output another one
>  	git log -z --pretty=oneline --reflog >actual &&
>  	test_cmp expect actual
>  '

This is also 6/6 in this series to submit a bunch of these sorts of
issues, which I submitted back in July:
https://lore.kernel.org/git/cover-0.6-00000000000-20220721T064349Z-avarab@gmail.com/

Re: [PATCH] t4205: don't exit test script on failure

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> This is also 6/6 in this series to submit a bunch of these sorts of
> issues, which I submitted back in July:
> https://lore.kernel.org/git/cover-0.6-00000000000-20220721T064349Z-avarab@gmail.com/

Such a comment is the least productive, I am afraid.

When the series originally did not get any traction would have been
a good time to ask others for reviews to push it forward, but not in
a thread of other people.

Thanks.

Re: [PATCH] t4205: don't exit test script on failure

[Ævar Arnfjörð Bjarmason]

On Fri, Dec 02 2022, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> This is also 6/6 in this series to submit a bunch of these sorts of
>> issues, which I submitted back in July:
>> https://lore.kernel.org/git/cover-0.6-00000000000-20220721T064349Z-avarab@gmail.com/
>
> Such a comment is the least productive, I am afraid.
>
> When the series originally did not get any traction would have been
> a good time to ask others for reviews to push it forward, but not in
> a thread of other people.

I think it's a productive comment on a patch to point out that it's the
exact same change someone else has submitted independently before.

In my mind that's better than a "LGTM" or "Reviewed-by". Those are both
versions of "I looked over your work", but if you independently come up
with the same thing that's usually a stronger sign that the proposed
solution is a good one.

If you read it as complaining that my series didn't get picked up that
wasn't the intent. I don't care either if René's commit ends up on
master, or mine. Just as long as the issue gets fixed.

I did just re-submit that series just now, re-rolled to get past a minor
conflict, and with a few other changes.

It's still just the tip of the iceberg in terms of these issues in the
test suite, but hopefully it can get picked up this time around, and
perhaps get some reviewer interest...

1. https://lore.kernel.org/git/cover-v2-0.8-00000000000-20221202T000227Z-avarab@gmail.com/

Re: [PATCH] t4205: don't exit test script on failure

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> I think it's a productive comment on a patch to point out that it's the
> exact same change someone else has submitted independently before.
>
> In my mind that's better than a "LGTM" or "Reviewed-by". Those are both
> versions of "I looked over your work", but if you independently come up
> with the same thing that's usually a stronger sign that the proposed
> solution is a good one.

Not necessarily.

Past effort that did not fare well needs to be re-examined to make
sure it was not picked up because it was crappy, because two people
independently coming up with the same crappiness does not help us
build more confidence.  Instead of forcing other reviewers waste
their time looking at older threads, it would help to explain what
you find good in the patch you are reviewing.

Re: [PATCH] t4205: don't exit test script on failure

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> In my mind that's better than a "LGTM" or "Reviewed-by". Those are both
>> versions of "I looked over your work", but if you independently come up
>> with the same thing that's usually a stronger sign that the proposed
>> solution is a good one.
>
> Not necessarily.
>
> Past effort that did not fare well needs to be re-examined to make
> sure it was not picked up because it was crappy, because two people
> independently coming up with the same crappiness does not help us
> build more confidence.  Instead of forcing other reviewers waste
> their time looking at older threads, it would help to explain what
> you find good in the patch you are reviewing.

Related to this, another thing you often do is very helpful: to say
that the patch being proposed solves the same problem another patch
that is already in our tree solved in a different part of the code
base.  If it was good for another part of the system, it is likely
that the same solution may be a good fit for the part being touched
as well.

Compared to that, referring to an earlier patch that failed to hit
our code base is not all that helpful.

Thanks.