| commit | 832c68b3c210267c93e1dcb2f2763372339ca36c | |
| author | Eric Sunshine <sunshine@sunshineco.com> | |
| Thu, 1 Sep 2022 00:29:49 +0000 (1 00:29 +0000) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Thu, 1 Sep 2022 17:07:41 +0000 (1 10:07 -0700) | ||
| tree | 3141f27c3958b96cbb05ddd3f7feafcc4328f79e | treesnapshot (tar.gz zip) |
| parent | a8f30ee0502b89ecb660af36784f653a8c3fb20d | commitdiff |
chainlint.pl: don't flag broken &&-chain if failure indicated explicitly
There are quite a few tests which print an error messages and then
explicitly signal failure with `false`, `return 1`, or `exit 1` as the
final command in an `if` branch. In these cases, the tests don't bother
maintaining the &&-chain between `echo` and the explicit "test failed"
indicator. Since such constructs are manually signaling failure, their
&&-chain breakage is legitimate and safe -- both for the command
immediately preceding `false`, `return`, or `exit`, as well as for all
preceding commands in the `if` branch. Therefore, stop flagging &&-chain
breakage in these sorts of cases.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are quite a few tests which print an error messages and then
explicitly signal failure with `false`, `return 1`, or `exit 1` as the
final command in an `if` branch. In these cases, the tests don't bother
maintaining the &&-chain between `echo` and the explicit "test failed"
indicator. Since such constructs are manually signaling failure, their
&&-chain breakage is legitimate and safe -- both for the command
immediately preceding `false`, `return`, or `exit`, as well as for all
preceding commands in the `if` branch. Therefore, stop flagging &&-chain
breakage in these sorts of cases.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>